Have you ever heard of platforms such as Amazon Web Services (AWS), Google Cloud Platform or Microsoft Azure? Do you know how to get the most benefits from them?
If we do not properly understand the different services offered and how they can interact with each other, transitioning toward Cloud Computing can be a huge challenge.
Architecture opposed to the Cloud: Monolithic
A monolithic architecture is usually composed of a single service layer that is responsible for two things that are especially linked:
- The user interface (UI)
- The server layer (API)
On the other hand, these two components need to be independent from one another. It is one of the reasons why Single Page Applications (SPA) are that popular; they allow to have a structure on the customer’s side, but the communication with the server goes through an API type access point (with REST and GraphQL, which is another subject altogether.)
This rather simplistic architecture, however, has a fundamental importance. As human beings, it allows us to use our creativity to the maximum while eliminating as much as possible all the complexities that can appear during the software development. Even with a few users, everything can be deployed on a server and nobody is the wiser!
That until the day we cross the critical threshold and the application starts to be slow. Your architecture absolutely needs to grow (scaling).
You have two choices for scaling:
- Vertically: by adding more memory or processors to the current server
- Horizontally: by adding more machines and more servers
The horizontal approach can reap the most benefits when transitioning toward Cloud Computing.
Start by transferring your virtual machines in the Cloud
Hosting virtual machines on the Cloud is a basic service offered by all platforms. It’s normal; most web applications are developed with server technologies that require access to said servers.
That is why a lot of companies have already migrated their servers toward the Cloud. Not only are the maintenance costs reduced, but security is also improved. However, it should be noted that this security is not magical. For example, Amazon Web Services mention a Shared Responsibility Model.
It remains a great responsibility for us to ensure that our infrastructure is well secured. If no one on your team has basic security knowledge, it requires a lot of learning in order to implement what might one day make the difference between being hacked or not. Let’s examine the example of authenticating users with their password.
The Components that can be replaced by Cloud Services
As you might have experienced in previous projects (or you might even be a user unknowingly), there are still some systems around that save passwords with an easy to hack encryption. As soon as the database is accessed illegitimately, it is easy to extract a list of users and to decode their passwords.
It is the perfect example of a part of infrastructure that can be migrated toward a Cloud Computing service. AWS offers Cognito, Azure offers the Directory Service and Google offers Firebase. They all have documents and examples that allow you to start using them easily.
The same exists for file storage, notifications and others. Here is a short list with the equivalents for each provider:
This table is an incomplete list, because new services are being released every month by each platform to help application development. Whether in the field of infrastructure, artificial intelligence or the Internet of Things (IoT), the competition is fierce and as a consumer, you can only benefit from it.
Separating the domains by expertise with the Bounded Context
Before being able to further segment our application, we first need to segment our own software to have components that are independent from one another.
To achieve that, we can use a pattern from Domain-Driven Design: the Bounded Context. It proposes to divide the application’s business domain in several contexts. These contexts will become our microservices. The goal here is not to get into the details of this subject, but I strongly invite you to read more about it.
Further segmentation with microservices
Using several services as components of the architecture, it becomes more and more segmented. If we take a look at the application we presently have, it is as much segmented but it is all deployed on the same machine.
That is why if our domains are well divided and none of them is really dependent on the other, the transition toward a microservice boils down to adding an entry point and making a container out of it.
Then, containers can be managed with the help of an orchestrator that offers to centralize your services through the different basic technologies used by Cloud Computing platforms.
Without realizing it, I just covered two of the four main axis of the Cloud Native approach. Supported by the Cloud Native Computing Foundation, it is an approach based on many open-source systems to deploy and manage the applications abstracting the infrastructure. The goal is for the programmers to optimize usage of resources (to save on infrastructure costs), while having the possibility to quickly build applications.
A Cloud Native application is ideally designed to respect Resilience, Agility, Operability and Observability.
Resilience allows us to monitor and manage errors, instead of focusing on preventing them. Since Cloud Computing platforms offer several separate components, we need to be able to build the system around a dynamic environment. If a process creates an error, an automatic step back should be possible so the process can quickly start again where the problem occurred.
Agility mainly comes with microservices. The more the components are small and separate, the more deployments will be quick and our delivery iterations will be close to one another.
Operability gives us control on an application’s lifecycle from the application itself, instead of depending on monitoring tools and external processes. The goal is to give the most responsibilities possible to developers and avoid getting into cases where we need to wait on someone else to investigate or restart the application.
Observability gives all the necessary information (in the form of metrics) to report on the application and better understand problems before they get to the users’ level. Response time, number of errors and memory usage are only examples that can push us to be more proactive and improve upstream.
In summary, here are four work axes to get closer to Cloud Native architecture:
- Composition of the application: it needs to be composed of a group of services.
- Logs and Events: it needs to be easy and simple to signal an event or to write in the logging.
- Application Delivery: it needs to be deployable as easily in an environment.
- Common Control & Ops: it becomes possible to automate the steps and have a DevOps process.
Start transitioning toward the Cloud today!
You may see a change of this magnitude can as enormous and costly, but don’t forget that you can simply start by hosting your application on the Cloud.
Then, like a child playing LEGO, you can integrate different services according to your needs and have an easier time when the software needs to evolve.
Finally, it is by dividing your huge LEGO piece — your application — that you will be able to change the structure quicker without breaking everything.