Cloud native architecture
How to architect when building cloud native applications?
A cloud native architecture is leveraging the capabilities of the cloud platform you are using.
Compared to traditional infrastructure there are some differences, that allow for a different approach:
- Flexibility: A pay-as-you-go pricing model allows you to be flexible with the resources you use.
- Elasticity: Quickly provision and de-provision resources based on current demand.
- Global infrastructure: Deploy your application close to your customer. Deploy in multiple regions to increase resilience.
- Platform services: Speed up development and reduce operational burden with ready to use platform services.
If you don’t leverage any of these aspects, you might end up just paying too much for your virtual machine.
The overarching design goals of a cloud native architecture are shipping business value fast and providing an excellent user experience.
There are many things to consider when designing a cloud native system. So let’s have a look at some of these …
Automation
Deploy frequently at low risk with deployment pipelines that contain steps for quality assurance, vulnerability scanning and compliance checks. Automate your infrastructure setup with infrastructure as code to reduce mean time to recovery and be able to spin up dynamic environments e.g. for a feature branch. Setup auto-scaling to react on changes in resource demand without human intervention.
State
Stateless applications are easy to scale as you can have as many replicas as you need. These can be repaired easily in case of failure by simply spinning up a replacement. Roll-backs of bad deployments are also painless.
Persistence
Persistence might have a different lifecycle than your application or service environment. So it might make sense to manage it separately. If done properly you can do blue/green deployments of your application infrastructure while retaining your persistence. Polyglot persistence can be cost efficient and helpful to provide an excellent user experience.
Service-oriented / Microservices
Separate / couple your systems wisely. Use splits tactically considering different requirements, organizational aspects, resilience and performance. With a service-oriented or microservice architecture different parts of the system can be scaled independently, but keep in mind that distributed systems add complexity that needs to be managed. Declarative APIs, technology agnostics protocols and service level objectives (SLOs) can be valuable in this regard. The size of services must make sense within your organizational setup — small teams and small services combine well. If you want to be flexible with responsibilities for your subsystems, consider smaller services — that way, you can transfer responsibilities between teams more gradually.
Change
As change will happen, accept it and anticipate it. Think about replaceability. If you can revise an architectural decision easily (low cost of change) don’t overthink. The higher the cost of change, the more investment into the decision itself or exploration of ways to reduce the cost of change might be required. Be aware, that it’s not always easy to spot when a decisions will be hard to revise.
Cloud native architecture is quite a broad topic, so I just focused on what I consider the essential aspects in this post. Probably I missed something important.
What are essential aspects of cloud native architecture for you?
Let me know via Twitter or LinkedIn.
Originally published at https://www.danielklemm.com.