Engineering and architecting applications in the cloud is different to on-premises. I wanted to explore high level approaches to how you decide on architecture and the stack used for the application.
Before writing, I did some research, what I expected to find was vendors saying why their tools are better than other vendors, for the most part this was right, expect for the cloud platforms.
What I want to explore over the next few posts on the wider topic of Architecting for the Modern Cloud, is; why do we architect in a specific way and why do we choose certain patterns over others, and even, why do we use certain languages and tools over others.
Breaking it down
I wanted to break this down into more manageable chunks, focusing on specific themes within application architecture, but while still providing useful information based on both my experience and research.
With that, here are the topics I want to explore:
- Microservices vs monolithic
- Relational databases vs schema-less databases
- Selecting the right language
Hey! What about cloud platforms?
Staying agnostic talking about cloud platforms is going to be tricky for me. To be honest and up front, most of my career has been spent on the Microsoft Azure stack, so I’m not really in a position to talk about the competitive advantages of one or the other.
Nor is that I feel useful when cloud platforms are now mature. I will say however, that common themes across all these subjects will be existing experience with a tool or platform, desired outcomes, and team structure.
For instance, if you have a team of experienced Azure engineers and .NET developers, as well as some seasoned SQL DBAs, then you are not going to write your application in Node JS, on AWS, using MongoDB.
I mean, you may choose to do that, and if you have reasons for that, then that’s fine. Architecture is all about delivering value in a solution, not delivering something that presents an opportunity to further your career.
A little about cloud native
Plenty is written about cloud native, what it is, how it works, and what it means. But cloud native is much more than just running on the cloud. You can still deploy an application on virtual machines in the cloud, but this doesn’t make it cloud native.
When building cloud native applications in the cloud, you need to ask yourself some questions about the application.
- Can your application handle dependencies being moved?
- Can you scale up, or down according to demand?
- Can you take advantage of spot pricing in your provider?
- Can the application be moved to a different container node or server without minimal downtime?
- Can you backup, restore, and upgrade without downtime?
- Do you have visibility into your application when it goes wrong?
Summary
So with that, in the next post on this series, I’m going to try and look at the discussion of microservices vs monolithic in the cloud world and see where we get!
Martyn Coupland 