Cloud Native Architecture

6 key architecture qualities

Cloud Native Architectures enhance our ability to practice DevOps and Continuous Delivery, and they exploit the characteristics of Cloud Infrastructure. I define Cloud Native Architectures as having the following six qualities:

1. Modularity (via Microservices)
2. Observability
3. Deployability
4. Testability
5. Disposability
6. Replaceability

12 factor app

There are a lot of challenges we could face when designing and developing Cloud Native applications, so it is important to follow certain principles while developing Cloud Native applications. Heroku developed the Twelve-Factor App, which is essentially a manifesto describing the rules and guidelines that need to be followed to build a Cloud Native application. These factors serve as an excellent introduction to the discipline of building and deploying applications in the cloud. The Twelve-Factor App describes 12 design principles that are used in Cloud Native application architectures. We will see a brief summary of these principles here. To see more, visit the 12factor.net site. The 12-factor app methodology addresses the following challenges:

• How can you get to fail faster?
• How can you get everything you need ready so then, at a push of a button, you and your team can get your work done?
• How do you take that code and then through process make it available for production?
• And then how can you automate that process with continuous integration, continuous deployment, and even sometimes continuous delivery?
• How do you get people to change methodology? What are the processes that they need to define to do the work?

What are the 12 factors

• Factor 1: Codebase You need to build on top of one codebase, fully tracked with revision control and many deployments. Deployments should be automatic, so everything can run in different environments without work.
• Factor 2: Isolated Dependencies The second factor is about explicitly declaring and isolating dependencies because the app is a standalone and needs to install dependencies. This is why you declare what you need in the code. “Your development, your QA and your production have to be identical for 12-factor apps to actually work because when you scale for web, you can’t have any room for error.”
• Factor 3: Config Here you store your configuration files in the environment. This factor focuses on how you store your data — the database Uniform Resource Identifier (URI) will be different in development, QA and production.
• Factor 4: Backing Services You need to treat backing services like attached resources because you may want different databases depending on which team you’re on. Sometimes dev will want a lot of logs, while QA will want less. With this method, even each developer can have their own config file.
• Factor 5: Build, Run, Release You want to strictly separate the Build and Run stages, making sure everything has the right libraries. Then you put everything together in something that can be released and installed in the environment and then be able to run it. “As a developer, I want to be able to develop something that is this nice, tightly deliverable object, thing, that I can give to Ops. Ops then can put it in that environment and run it. And ideally, I will never hear from Ops again, because you’ve made it a well-defined solution” with few dependencies.
• Factor 6: Stateless Processes You want to make sure that stuff is stored in a backing store, meaning you’re able to scale out and do what you need to do. The app is executed in one or more stateless processes. As you scale up and out, you don’t want to have a state that you need to pass along.
• Factor 7: Port Binding Exporting services via port binding allows your internal customers to access your endpoints without traversing security. Then, you are able to access your app directly via a port to know if it’s your app or another point in the stack that isn’t working properly.
• Factor 8: Concurrency Small, defined apps allow scaling out as needed to handle the varying loads. Break your app into much smaller pieces and then look for services out there that you either have to write or can consume.
• Factor 9: Disposability Make sure changes can take effect very quickly. It’s about making sure you can start up and take down fast. And that you can handle a crash.
• Factor 10: Dev-Prod Parity Development, staging and production should be as similar as possible. Continuous deployment needs continuous integration based on matching environments to limit deviation and errors. If you keep dev, staging and production as similar as possible, anyone can understand it and release it. This is of course simply good development but it also enables a lot more scalability.
• Factor 11: Logs Your app only worries about creating a sort of event stream. Then, depending on the configuration, you can decide where that log will publish.
• Factor 12: Admin Processes Your admin tools ship with the product. For example, do not go messing with the database. Instead, use the tooling you built alongside your app to go and check the database. This also means that the privileges are the same across your system — no more special cases that put your security at risk.

Reference: 12 factor apps in plain english