put terrible microservices in containers. Manage containers with Kubernetes. Put evrything on AWS cloud. This time it WILL work, I promise!

Reality:
There are an infinity of ways to create poor implementations and only a few ways to write good ones and even fewer ways to make something with efficiency, longevity, and that is easily maintainable. As with many things one can choose any two of good, fast, and cheap but never all three.

If you can’t even do a monolith right, you shouldn’t even be thinking of microservices yet.

Well the whole idea of microservices is to have less to conquer. The cost is obviously communication, which is always a slowdown in any system of entities. If you don’t intend to distribute the work among diverse and distant teams, it is my opinion that microservices are an overhead and pain you don’t need.

Source: https://www.facebook.com/126000117413375/posts/3214565311890158

Code is easy, State is hard. Learning how to deal with your monolithic relational databases in a microservices structure is key to keeping pace in a quickly changing workplace.

“Microservices architecture is not appropriate all the time”.

Revisiting the Unix philosophy in 2018
https://opensource.com/article/18/11/revisiting-unix-philosophy-2018?sc_cid=7016000000127ECAAY

The old strategy of building small, focused applications is new again in the modern microservices environment.

In a nutshell that philosophy is: Build small, focused programs—in whatever language—that do only one thing but do this thing well, communicate via stdin/stdout, and are connected through pipes.

Sound familiar?

Yeah, I thought so. That’s pretty much the definition of microservices offered by James Lewis and Martin Fowler

Mikropalveluarkkitehtuurista on tulossa yhä enemmän standardivaihtoehto tulevaisuuden ohjelmistojen toteutustapoja miettiessä.

What is distributed tracing and why is it so important in a microservices environment?

Microservices have become the default choice for greenfield applications. After all, according to practitioners, microservices provide the type of decoupling required for a full digital transformation, allowing individual teams to innovate at a far greater speed than ever before.

Microservices are nothing more than regular distributed systems, only at a larger scale. Therefore, they exacerbate the well-known problems that any distributed system faces, like lack of visibility into a business transaction across process boundaries.

it’s extremely common to have multiple versions of a single service running in production at the same time

we have is chaos. It’s almost impossible to map the interdependencies and understand the path of a business transaction across services and their versions.

This chaos ends up being a good thing, as long as we can observe what’s going on and diagnose the problems that will eventually occur.

A system is said to be observable when we can understand its state based on the metrics, logs, and traces it emits.

Metrics solutions like Prometheus are very popular in tackling this aspect of the observability problem. Similarly, we need logs to be stored in a central location

Logstash is usually applied here, in combination with a backing storage like Elasticsearch.

In monolithic web applications, logging frameworks provide enough capabilities to do a basic root-cause analysis when something fails. A developer just needs to place log statements in the code.

In microservices architectures, logging alone fails to deliver the complete picture.

A common strategy to answer this question is creating an identifier at the very first building block of our transaction and propagating this identifier across all the calls, probably by sending it as an HTTP header whenever a remote call is made.

In a central log collector, we could then see entries

This technique is one of the concepts at the core of any modern distributed tracing solution

trace displayed in Jaeger, an open source distributed tracing solution hosted by the Cloud Native Computing Foundation (CNCF)

Like with logging, we need to annotate or instrument our code with the data we want to record.

we can use an API such as OpenTracing, leaving the decision about the concrete implementation as a packaging or runtime concern

we could turn on the distributed tracing integration for Istio, a service mesh solution

it’s easy to feel helpless while conducting a root cause analysis when something eventually fails and the right tools aren’t available. The good news is tools like Prometheus, Logstash, OpenTracing, and Jaeger provide the pieces to bring observability to your application.

The tech giant is extending the Kubernetes container service with Istio, its latest open source software release

In short, Istio is an “open platform to connect, manage, and secure microservices”.

Otherwise known as a ‘service mesh’, the aim is to unify traffic flow management, access policy enforcement and telemetry data aggregation across microservices into a shared management console, regardless of environment.

Originally launched in May 2017, version 1.0 becomes generally available on 1 August 2018 and was announced on stage during Google Next

Coming into this year, CoreOS’s Alex Polvi predicted that Istio, an open source tool to connect and manage microservices, would soon become a category leading service mesh (essentially a configurable infrastructure layer for microservices) for Kubernetes. Today we celebrate a milestone that brings us closer to that prediction: celebrating the general availability of Istio 1.0.

Istio provides a method of integrating services like load balancing, mutual service-to-service authentication, transport layer encryption, and application telemetry requiring minimal (and in many cases no) changes to the code of individual services. This is in juxtaposition to other solutions like the various Java libraries from Netflix OSS.