Microservices and Serverless

Download as txt, pdf, or txt
Download as txt, pdf, or txt
You are on page 1of 3

This course is designed for all kinds of Cloud practitioners, including anyone who

wants to design, develop, deploy, manage or secure applications and solutions on


public, private or hybrid cloud platforms. By the end of this course, you will have
a solid foundation for microservices and serverless and will have deployed
microservices on the cloud and integrated them with serverless compute.

The emergence of cloud computing has brought about a lot of changes to modern
software development. Rather than large annual releases on physical mediums like
CDs, modern software is increasingly released on the cloud, provided cost
reduction, decreased time to market, and increased agility. These changes allow
organizations to keep pace with their competitors and bring new innovations to
market in ways that previously would have been unthinkable.

In addition to methodologies like agile and DevOps, microservices have emerged as


an architectural model suited for cloud development. Rather than building large
applications, known as monoliths, that perform all the functionality, microservices
break down larger applications into smaller pieces that are independently
maintainable and scalable, providing a host of benefits. This architecture is used
at the largest software organizations in the world because it provides cost
benefits, team autonomy, and so many other advantages.

Likewise, serverless has emerged as an increasingly popular compute option in the


cloud era. Giving developers and operators the ability to run applications without
managing underlying infrastructure has freed up resources at organizations that can
now focus on developing business logic and furthering the mission and goals of
their organization, rather than having to maintain servers and complex
infrastructure. The Cloud Native Computing Foundation—known as CNCF—conducts annual
surveys to discern where and how cloud-native technologies are being adopted. The
2020 survey indicates that just under a third of respondents are already using
serverless in production, with 21% evaluating it and 14% planning to use it in the
next 12 months. Serverless is positioned to become an even larger force in cloud
computing in the years ahead because of its myriad advantages, and understanding
its purpose is vital for any cloud developer.

Les microservices font de chaque composant d'application son propre service.

En français, cette phrase signifie que dans une architecture de microservices,


chaque élément ou composant d'une application est transformé en son propre service
indépendant. Plutôt que de concevoir une application comme une entité monolithique
unique, on la divise en de plus petites parties, appelées microservices, qui
fonctionnent de manière autonome et peuvent être développées, déployées et évoluées
indépendamment les unes des autres. Cette approche favorise la modularité, la
flexibilité et la facilité de gestion dans le développement d'applications.

Les microservices permettent à chaque composant individuel de s'adapter en fonction


de la demande.

En d'autres termes, dans une architecture de microservices, chaque composant ou


service peut être ajusté pour répondre à des niveaux de demande spécifiques. Plutôt
que de dimensionner l'ensemble de l'application pour gérer la charge maximale
prévue, vous pouvez ajuster chaque microservice séparément. Cela signifie que les
parties de l'application qui sont les plus sollicitées peuvent être mises à
l'échelle de manière indépendante, ce qui permet d'optimiser les ressources et de
garantir une réponse efficace aux besoins de l'utilisateur. Cette capacité de mise
à l'échelle granulaire est l'un des avantages clés des architectures de
microservices.
Les microservices réduisent les risques associés aux changements car les composants
peuvent évoluer indépendamment.

Dans une architecture de microservices, chaque service est autonome et peut être
développé, déployé et mis à jour de manière indépendante des autres services de
l'application. Cela signifie que si vous devez apporter des modifications à une
partie de l'application, vous pouvez le faire sans perturber le fonctionnement des
autres parties. Par conséquent, les risques de régression ou d'impact involontaire
sur d'autres parties de l'application sont considérablement réduits.

En résumé, les microservices permettent une plus grande agilité dans le


développement et les mises à jour logicielles, car ils minimisent les risques
associés aux changements en permettant à chaque composant de fonctionner de manière
autonome.

While there are many patterns for doing microservices well, an equally significant
number of patterns exist that can quickly get any development team into trouble.
The following are some of the don’ts while developing microservices:

Don't build microservices

The first rule of microservices is don’t start with microservices. When you
determine that the monolithic application's complexity negatively affects
application development and maintenance, consider refactoring that application into
smaller services.

When the application becomes too large to update and maintain easily, these
microservices will become ideal for breaking down the complexity and making the
application more manageable.

However, until you feel that pain, you don’t even have a monolith that needs
refactoring.

Not taking automation seriously

If you have a monolith application, you only need to deploy one piece of software.
Once you move to a microservices architecture, you will have more than one
application with each having different code, test, and deploy cycles.

Attempting to build microservices without either:

proper deployment and monitoring automation, or

managed cloud services to support your now sprawling, heterogenous infrastructure

is asking for a lot of unnecessary trouble.

So, when you are building microservices, always use DevOps or cloud services.

Don’t build nanoservices


If you go too far with the micro in microservices, you could easily find yourself
building nanoservices! The complexity of which will outweigh the overall gains of
microservices architecture.
Lean toward creating larger services and create smaller services when:

Deploying changes becomes difficult

The common data model becomes overly complex

Loading and scaling requirements no longer synchronize and affect application


performance

Don’t turn into SOA

The two concepts; microservices and service-oriented architecture (SOA) are often
confused with one another because, at their most basic level, both build reusable
individual components that can be consumed by other applications.

However, microservices are fine-grained with independent data storage for each,
that is, the bounded context.

A microservices project that morphs into an SOA project will likely buckle under
its own weight.

Don’t build a gateway for each service

Instead of implementing end-user authentication, throttle, orchestrate, transform,


route, and analytics in each service, you should use an API Gateway.

An API gateway is an API management tool that sits between a client and your
collection of backend services.

This will become central to the above-mentioned non-functional concerns and will
avoid re-engineering them with each service.

Conclusion
The aim of microservices is to solve the three most frequent challenges, that is,
enhance customer experience, be flexible to new requirements, and reduce costs by
providing business functions as fine-grained services.

But while doing so, you should avoid the pitfall of the above-mentioned anti-
patterns making microservices a nuisance to your development, delivery, and
management requirements.

You might also like