Microservice Patterns and Best Practices

Vinicius Feitosa Pacheco

• Publisher: Packt Publishing
• Year: 2018
• ISBN:
  9781788471206
• Edition: 1
• Topic: Computer Science
• Subtopic: Programming Languages
• Index: Computer Science

Explore the concepts and tools you need to discover the world of microservices with various design patternsAbout This Book• Get to grips with the microservice architecture and build enterprise-ready microservice applications• Learn design patterns and the best practices while building a microservice application• Obtain hands-on techniques and tools to create high-performing microservices resilient to possible failsWho This Book Is ForThis book is for architects and senior developers who would like implement microservice design patterns in their enterprise application development. The book assumes some prior programming knowledge.What You Will Learn• How to break monolithic application into microservices• Implement caching strategies, CQRS and event sourcing, and circuit breaker patterns• Incorporate different microservice design patterns, such as shared data, aggregator, proxy, and chained• Utilize consolidate testing patterns such as integration, signature, and monkey tests• Secure microservices with JWT, API gateway, and single sign on• Deploy microservices with continuous integration or delivery, Blue-Green deploymentIn DetailMicroservices are a hot trend in the development world right now. Many enterprises have adopted this approach to achieve agility and the continuous delivery of applications to gain a competitive advantage. This book will take you through different design patterns at different stages of the microservice application development along with their best practices.Microservice Patterns and Best Practices starts with the learning of microservices key concepts and showing how to make the right choices while designing microservices. You will then move onto internal microservices application patterns, such as caching strategy, asynchronism, CQRS and event sourcing, circuit breaker, and bulkheads. As you progress, you'll learn the design patterns of microservices.The book will guide you on where to use the perfect design pattern at the application development stage and how to break monolithic application into microservices. You will also be taken through the best practices and patterns involved while testing, securing, and deploying your microservice application. At the end of the book, you will easily be able to create interoperable microservices, which are testable and prepared for optimum performance.Style and approachComprehensive guide that uses architectural patterns with the best choices involved in application development

The Microservice Tools

Some issues are always questionable or controversial when it comes to choosing a microservice stack. Much is discussed regarding the performance, practicality, cost, and scalability. Most of what is discussed is background views; many of these are valid opinions and many others not so much.

Obviously, the history of the development team should be considered in any technical decisions regarding the stack and implementation. However, at times, it is necessary to leave some comfort zones behind to develop a product. A comfort zone can be a programming language, a protocol, a framework, or a database, and they can limit a developer's ability to move at speed. The developed application then becomes more and more scalable.

In this chapter, you will be working on points that should be examined for internal discussions and development teams. In the end, it is always important to understand that the development stack is not an amusement park; to develop the best product, we should always be considering the aspects of cost and scalability.

Some criticisms will be made throughout this chapter. None of these criticisms seek to depreciate or affirm the best technology to be applied. All analysis is performed here with the full focus on the end product of this book, which is a news portal using the microservice architecture.

In this chapter, we'll look at the following:

• Programming languages
• Microservices frameworks
• Binary communication
• Message broker
• Caching tools
• Fail alert tools
• Locale proof performance

Programming languages

Discussing programming languages is something that can be controversial, primarily because many developers tackle programming languages in a great hurry. However, programming languages should be seen as what they really are, a working tool. Every tool has a specific purpose and programming languages are no different.

It is just an analysis focused on our business, the news portal, which we will use to get to the point of how to select a language.

A big plus point for microservices is the heterogeneity of applications. In other words, it is not necessary to think of a single stack to apply to all business areas. We can thus define each microservice stack that applies, including when it comes to a programming language.

Basically, any programming language that meets the internet can be used in microservices. The difference is due to the requirements and domain boundaries that must be encoded. Some domain indicators can help us in this process.

If a microservice has strong mathematical processing load requirements, or where immutability of values is something positive, functional languages would be an interesting way to go. If there is a demand for processing large masses of data, then a compiled language with a robust virtual machine may be the answer.

Remember that missing this strategy could compromise the project deadline or even the entire application architecture. The fact is that several aspects should be analyzed before any definition, such as:

• Proficiency
• Performance
• Development practicality
• Ecosystem
• Scalability cost

Proficiency

The first goal for a software developer is to achieve proficiency in any programming language or paradigm. Achieving a good level of proficiency is not easy, and some languages may have a steeper learning curve than others.

Problems arise when proficiency in a language ends up creating a comfort zone from which a developer or team finds it difficult to leave. In contrast, a myth must be overthrown: that one programming language is much easier than the other. Obviously, a language may prove simpler than another at first, but in the end what will count is the practice time and the number of scenarios experienced by a developer with a programming language.

Another myth that must be fought is that all languages are equal at their core and that only the syntax changes. This is one of the worst possible errors that can be committed. Languages can be quite different in internal design and performance, although they have similar syntaxes.

Proficiency is something that should be considered when deciding which language to apply for a microservice. However, it should not be as decisive as this one.

Performance

This is a key requirement in choosing a programming language for a microservice. When we talk about performance for microservices, there are many points where performance can be a problem: the network communication layer, access to the database, where the servers are available. All these points can be problematic for microservices. The programming language cannot be another can of slowness.

When the target is microservice performance, no matter the skill of the development team, it should be used for best second language benchmarks and stress tests.

Something that often creates misunderstanding is considering the speed of a development team to implement a feature and performance requirement. Performance is related to a metric similar to how a code behaves when responding to a request or performing a task. Definitely, personal or team performance is not included in this metric.

Development of practicality

This is the requirement responsible for measuring the speed applied to a feature going into production. Development of practicality touches two teams: the development team that already exists and the development team that can come into existence.

As has been said before, the word success can be a problem for an application and consequently for the product owners. Keeping the base code simple and understandable is fundamental to facilitating code changes and for implementing new features.

Good programming practices can help us to understand the legacy code, but often the language itself, because the verbiage is not very friendly.

There are scenarios where a programming language, given its characteristics, is extremely performative. But the cost of time to implement something new, though it may be simple, can be very expensive.

Think of a scenario where a start-up has just launched its product. The product is also a Minimum Viable Product (MVP) and was launched in the market to go through public validation in general. If this MVP succeeds, it is essential to publish new features as quickly as possible. In this case, the performance is not the problem, but the practicality of new interactions on the code.

When we are developing microservices and we decide to use this programming language it is an important aspect to be noted.

Ecosystem

The ecosystem of a programming language is a crucial one.

We all know that parts of the frameworks are almost essential to gain speed and simplicity in the development of any application. With microservices, the scenario is identical.

It is feasible that features are not developed by something being blocked on the technical side. Of course, the microservices architecture is providing a plurality of very broad tool options. However, understanding the possible drawbacks when choosing a programming language, and therefore inheriting its ecosystem, is critical to the engineering team responsible for the implementation.

There are cases where a programming language is very performative, but the ecosystem that would win on development speed compromises performance. This type of situation is far more common than you think.

Another point is when a language is very simple, but the frameworks are not mature enough; you end up generating unnecessary complexity.

Observing the ecosystem of a programming language, and understanding the risks it is assumed we gain by inheritance, is fundamental to the adoption of a language.

Scalability cost

The cost of scaling an application is linked to two major factors. The first is the speed of the selected stack used to implement the software. Specifically, the speed and capacity of processing algorithms and answering requests. The second factor is the ability to scale the application of the business part. How long is it applied to features and especially the predictability of new features? The time to create something new or redesigning something that already exists is also expensive.

With microservices architecture, the cost of scalability is usually related to the concept of having smaller areas and parts which are less integrated. Even then this cost is very important.

Think of two applications, one with ...