Microservices (III)

Microservices (III)
Decentralized governance

One consequence of centralized governance is the trend in a single standardized technology platform. Experience shows that this approach converges-not every problem is a nail, nor every solution is a hammer. We prefer to use the right tools, but it is not common for an overall application to use different languages to a certain extent.

When components are divided into multiple services, we have a choice when creating them. Do you want to use Node. js to create a simple report page? Try it out. Is a rough near real-time component built with C ++? Okay. Do you want to replace a database to adapt to the reading behavior of a component? We have technology to rebuild it.

Of course, just because youYesDoing something doesn't mean youShould-But in this way, it means you have the option to partition your system.

When building microservices, the team prefers a different and standard approach. Instead of using a set of standards written on paper, they prefer to generate useful tools so that other developers can use them to solve similar problems. These tools are usually generated in practice and widely shared, sometimes, but do not reject the use of internal open source mode. Just as Git and github have become the first choice for version control systems, open source practices are becoming increasingly common internally.

Netflix is a good example of organizations that follow this idea. Share useful and most important code libraries that have been tested over time and encourage other developers to solve similar problems in similar ways. You can also select different methods if necessary. Shared libraries are often concentrated on data storage, inter-process communication, and infrastructure automation Frequently Asked Questions. Detailed descriptions will be provided after infrastructure automation.

For the microservice community, daily management costs are often inconspicuous. This does not mean that the society does not pay attention to service agreements. On the contrary, because it is often more attention. This is only because they are looking at the management of these conventions in different ways. Microservices often use Tolerant Reader and Consumer-Driven Contracts (CDC ). They help service conventions become independent. Using CDC as a part of building can increase confidence and provide quick feedback on whether your service is effective. In fact, we know that a team in Australia is using CDC to build new services. They use some simple tools that allow defining conventions for services. This is part of automatic building, even before the code of the new service is generated. The only purpose of service establishment is that it satisfies the Convention-an elegant method to avoid the "YAGNI" dilemma [9]. These technologies and tools grow together with them. by reducing the time coupling between services, the central agreed management needs are limited.

Perhaps the highest point of decentralized governance is the building/running culture of Amazon. The team is responsible for all aspects of the software they build, including 24/7 of the software operation. Decentralization of this level of responsibility is definitely not the norm, but we also see more and more companies pushing their responsibilities to the development team. Netflix is another organization adjusted according to this ethos [11]. Waking up by your pager at every night is undoubtedly a powerful incentive, so that programmers should pay attention to quality when writing code. These ideas are about moving as far away as possible from the traditional centralized management model.

Scattered Data Management

There are many different ways to present distributed data management. At the most abstract level, this means that the conceptual models in the world between systems will be different. This is a common problem when integrating large enterprises. customers in the sales view are different from those in the after-sales view. Customers in the sales view may not appear in the after-sales view completely. They either have different attributes or have the same attributes but different semantics (the latter is worse ).

This problem is common among different applications, but it may also occur within the program, especially when the application is divided into independent components. A useful way of thinking is the Domain-Driven Design (DDD) Design concept. DDD divides a complex structure into multiple bounded context and maps the relationships between them. This process is useful in both the overall component architecture and the microservice architecture, but the natural correlation between the boundaries of services and context helps to clarify, as we described earlier, to enhance isolation.

In addition to decentralized decision-making in the conceptual model, microservices also make decentralized data storage decisions. Overall applications prefer a single logical database to store data, but enterprises tend to prefer a separate database that spans a series of applications-these decisions are driven by the vendor's copyrighted business model. Microservices are willing to allow each Service to manage its own database, either different instances of the same database or completely different database systems-a method called Polyglot Persistence. You can use polymorphism persistence in the overall component, but it seems to work more frequently with microservices.

Release/release + release/release + e24Lj2t/7O8cqxu + release + zvG83Lm5x7 + 197f + release/JxNzWu8rH1 + release/release + vJzNK10NDOqs/release + zL2c/ s06bQ6Mfzo6zTw9K70Km3tM/ytKbA7bTtzvO1xLLZ1/fingerprint = "infrastructure Automation"> infrastructure Automation

Infrastructure automation technology has been developing for many years-the evolution of the cloud, especially AWS, reduces the complexity of building, deploying, and operating microservices.
Many products or systems built using microservices are being built through teams with extensive continuous delivery (its predecessor, continuous integration) experience. In this way, the team builds the automation technology of the infrastructure that is heavily used by the software. Build the pipeline as shown below.

Figure 5: simple Pipeline Construction

Because this is not an article on continuous delivery, please pay attention to the main features here. We want to have as much confidence as possible that our software can work, So we run a lot of automated tests. The prompt above the MPs queue indicates that it is automatically deployed to each new environment.

An integrated application will be built, tested, and pushed quite well through these environments. It turns out that once you invest in the automation and productization of integral programs and then deploy more applications, it will not be terrible. Remember, one of the purposes of CD is to make deployment boring, so no matter whether it is one or three of its applications, it doesn't matter if it is boring [12].

Another field in which the team uses a lot of infrastructure automation is to manage microservices in products. As long as the deployment is boring, there is no big difference between the monolithic and microservices. On the contrary, the landscape is significantly different for operations.

JavaScript and XHTML, CSS, your server side language of choice, SQL and an ORM dialect. Hardly single language, but you know what we mean.
11: Adrian Cockcroft specifically mentions "developer self-service" and "Developers run what they wrote" (sic) in this excellent presentation delivered at Flowcon in November, 2013.
12: We are being a little disengenuous here. obviusly deploying more services, in more complex topologies is more difficult than deploying a single monolith. fortunately, patterns reduce this complexity-investment in tooling is still a must though.