The world of n-tier architectures is dead.
Well maybe not quite dead, but it is certainly not the foundation of design for new systems that it has been for many years. The advent of cloud systems along with the improvements in development tooling has pushed architects to design scalable systems that make the most of the cloud platforms and allow the focus to shift to business logic, rather than the platforms needed to deliver applications.
Recently, we have delivered a web application where the whole stack has been hosted on Azure’s serverless services, reducing the cost of ongoing management and, so far, reducing the overall cost of running. There have been many areas of learning across the stack of using all the services together so this series of posts will cover summaries of how each service works and some potential gotchas that we have found.
The services we are covering are:
- Data repository with Cosmos DB and Azure Storage
- Business logic with Azure Functions
- Web Application using Angular 5 including Service Workers for offline access
- Authentication with Azure B2C
- Continuous integration and deployment with Visual Studio Online
- Automated environment deployment using Azure Resource Manager
- Monitoring with Application Insights
Each post will cover a short overview of the platforms, how we are using them, how we develop with them and the areas that made us stop and think. The great thing is that each of these is well documented with how to use, and well supported with some patterns on how best to use them as well. For the most part, they are also supported with great tooling for development and deployment as well.
So would we use these again? The answer is a resounding yes, they have hugely reduced the amount of platform administration required, retained the same Microsoft technologies that we are familiar with and offered testable and supportable applications. We can make changes and deploy to a set of environments at the click of a button and with no downtime. We can even deploy to new environments or beta test alongside our existing environment with minimal effort. If the application becomes more popular, there is no need to do anything as it automatically scales as needed. Storage costs are kept low by automatically moving unused files to cheaper storage until they are used again. And not once have we had to work out which server to log on to at 5 in the morning to find the issue in a random log file.
Serverless architectures do not fit every single situation – you may want to retain on-premises usage, or have too much dependency on third party software that does not fit this model. If you are not sure, contact us and we can have a chat on how we can assist with your software development needs in a rapidly changing technological landscape.
By Kevin McDonnell, Senior Technical Architect at Ballard Chalmers
About the author
Kevin McDonnell is a respected Senior Technical Architect at Ballard Chalmers, With a Master of Engineering (MEng), Engineering Science degree from the University of Oxford he specialises in .NET, Azure, the Office 365 development suite and has a broad understanding of the wider Microsoft stack. He listens to what clients are looking to achieve and helps identify the best platform and solution to deliver on that. Kevin regularly blogs on Digital Workplace topics and is a regular contributor to the monthly #CollabTalk discussions on Twitter.