Let’s compare the architectural style described in the previous post with the N-Tier architectural style of
building services. This involves many logical layers and physical tiers. It
comprises of WebTier, Messaging and Middle-tier and it may or may not involve a
FrontEnd. In the closed style, a layer can only call the next layer immediately
down and in the open style, a layer can call any of the layers below it.
Some of the benefits of this application include the
following: There is portability between cloud and on-premises, and between
cloud platforms. There is less learning curve for most developers. There is a
natural evolution from the traditional application mode, and it is open to
heterogeneous environment (Window/Linux)
Some of the challenges faced with this architectural
style include: The middle tier degenerates to a data access layer that just
does CRUD operations on the database which introduces unnecessary latency.
There is a monolithic design that prevents independent deployment of features.
Managing an IaaS application is more work than an application that uses only
managed services. It can be difficult to manage network security in a large
system.
Some of the best practices faced with this architectural
style include changes in load can easily be accomplished by scaling out.
Asynchronous messaging can decouple tiers. Semi static data can be cached. The
database tier can be configured for high availability, using a solution such as
SQL Server which is always on availability groups. It places a web application
firewall (WAF) between the front end and the Internet. It places each tier in
its own subnet and use subnets as a security boundary. The access is restricted
to the data tier.
Some examples include a simple web application, or an
application that migrates an on-premises application to Azure with minimal refactoring,
and a unified development of on-premises and cloud applications.
Conclusion: Both these
styles serve the purpose of a cloud service very well.
No comments:
Post a Comment