CANCEL
United States
United Kingdom
India
Germany
France
Canada
Russia
Spain
Brazil
Australia
Argentina
Austria
Belgium
Bulgaria
Chile
Colombia
Cyprus
Czechia
Denmark
Ecuador
Egypt
Estonia
Finland
Greece
Hungary
Indonesia
Ireland
Italy
Japan
Latvia
Lithuania
Luxembourg
Malaysia
Malta
Mexico
Netherlands
New Zealand
Norway
Philippines
Poland
Portugal
Romania
Singapore
Slovakia
Slovenia
South Africa
South Korea
Sweden
Switzerland
Taiwan
Thailand
Turkey
Ukraine
Cloud Native microservices is an approach to building microservices using the advantages of the cloud computing model, focusing on building our microservices and allowing our cloud to deploy, manage, and scale them.
Cloud architecture focuses on how, and now where it will give us the agility to deliver value to our products constantly, but first we need to understand what cloud computing.
Traditionally, organizations need to take care to provision specific infrastructure for their services. Whenever our applications need to scale, we need to buy more servers for them, many times using costly hardware provided by different vendors, and tanking a considerable amount of time to configure them within our systems.
That infrastructure approach usually is tied to a static capacity, so if we have a peak of load in our app, we need to buy more servers, and after that peak is gone, part of our infrastructure is unutilized, sometimes producing more costs just to maintain it or recycle into new services, and because configure isn't easy, probably we keep it as-is until the next peak comes in. Cloud computing is about using common and cheap hardware to create resources that could be used to dynamically deploy and run multiple applications that can be scaled either automatically or manually.
In a traditional architecture, we may have a database that has a certain capacity and is running in a particular server; if we need to scale it, we either upgrade the server resources, or we buy another server and configure. In a cloud, we create a database server and we scale the number of instances dynamically, and we get rid of unused instances if we don't need them anymore. The resources freed on the cloud could be used for creating or scaling other applications, and the cloud capacity overall could grow just by adding more conventional servers to it.
This approach allows organizations to go to a pay-as-you-go model for their infrastructure, instead of up-front buying servers, they could pay whatever resources their need for a specific period of time. Cloud applications are designed to easily be configured, since the overall idea is to have services that could be easily spawned in a short time. Cloud Native applications will use some kind of system, either provided by the cloud platform or the application itself, to be configured when new instances are created. Since we need to have services running in our cloud that could easily spawn and destroy, the majority of cloud use some kind of containerized applications.
Containers is a virtualization method that allows an operating system to run an application in isolated user space, controlling and limiting the resources for each contained application. For an application that runs on a container, it will work as if it is running in its own operating system. Most of the containers will not know that they are hosted on another operating system. This allows the host operating system to spawn or destroy those applications without affecting any part of the system and preventing impacts of one container to another.
Since these containers are running on a hosted system, when they need to start they will be faster than in a normal virtualization that requires a new operating system to boot. However, this implied that we could not spawn a container with a different system than the running host, so we could not run a Windows application as a process in a Linux host. Docker is probably the most used container system for cloud applications, however different cloud providers may choose different systems to run their applications. We will learn more about this topic in Chapter 7, Creating Dockers.
Organizations could choose different deployment models when creating cloud applications, let's review the most common models:
Private cloud is a cloud infrastructure for a single organization, and usually hosted internally in a self-hosted data center. They are usually capital intensive, and require allocation of space, hardware and environmental controls. Their assets have to be refreshed periodically, requiring additional costs. They usually need to be built and managed internally so they are not fully benefited from focusing on the how, not where concept.
Public cloud services are delivered in a network that is open for a public audience through a services provider that operates the infrastructure and their data centers. Providers manage access control and security for the organizations that use these services and usually allow connection through the internet, but organizations could choose to use direct connections, if required. They could be seen to be more expensive than a private cloud in the pay-as-you-go model, however considering the cost to build, upgrade and maintain a private cloud that is not always the truth.
Hybrid clouds try to take the benefits of mixing private and public clouds. An organization could choose to have a private cloud and linked to a public cloud to handle a peak of capacity or additional resources. Some organizations may choose this approach because a critical part of their business needs to be managed in-house in a private cloud but going to a public cloud for other matters.
There are several service models than can be offered to organizations by different cloud providers, sometimes more than one could be targeted by different products on the provider.
Here are the most common:
The most basic cloud service model offers computing infrastructure, virtual machines, and other resources, as a service to their users. They usually provide a high-level API or frontend to take care of low-level details such as networking, data partitioning, scaling, security, backup and so on. All of these are usually delivered as raw elements, so the cloud users need to maintain, patch and configure the different servers created by the platform.
Examples of these platforms are:
In this service model, the cloud platform provides services that allow customers to develop, run, and manage applications without the complexity of building and maintaining the infrastructure. Often this is facilitated via an application template system, that allows easy creation of new services. For example, providing a standard template for an application type, framework or even programming language.
With this, we could reduce complexity and the overall development of the application can be more effective, and maintenance and enhancement of the application are easier. Usually, the cloud will provide capabilities to patch and configure the different servers.
Examples of these platforms are:
In the SaaS model, users gain access to application software, because of which this model is sometimes called on-demand software. All the elements required for that software to run are managed internally on the platform. The cloud users do not need to take care of anything on the platform, neither the cloud, since everything is managed by the provider and is usually a pay-per-user basis.
Examples of these platforms are:
Now that we have a better understanding of cloud computing, we need to think why we should build Cloud Native microservices. If we have been following our microservices principles, we could easily deploy them in a cloud and take advantage of those platforms to benefit further from the microservices architecture. Our microservices could easily be scaled and managed, and since their isolation is a loosely coupling, they could easily fit in containers.
When we create microservices, we could make them cloud aware, and try to benefit from not just being microservices, but becoming Cloud Native applications, so they could fully benefit from the cloud computing model. Spring Cloud provides an easy to use the framework to make our cloud services independent of the cloud platform that they are hosted on and take the full benefits of the platform.
We will expand this further in Chapter 6, Creating Cloud-Native Microservices.
The rest of the chapter is locked
