35. Confidential, Dynatrace, LLC
Thank you for attending - Questions
• Start your free 15 day trial now and be
rewarded!
• Start your trial here!
http://bit.ly/2uZ2XIv
• Register in the next 5 days and be
rewarded with Beyond the Twelve-
Factor App and a Dynatrace t-shirt
• Don’t miss the rest of the Summer
Webinar Series….. There are still 6 more
parts!
37. 3 Key Takeaways: AAA
Auto discovery
Auto baselining
Auto problem analysis
Editor's Notes
At Dynatrace, we are proud partners with Red Hat and it is our mission to create the best performance management solution around OpenShift, OpenStack and Ansible.
In this presentation, I want to demonstrate that we are serious about this.
When we talk about microservices, we talk about dozens to thousands of small, interconnected components that each serve a single purpose.
The reason why they are so appealing is they have the potential to solve a variety of problems enterprises are seeing these days…
Microservices increase velocity: by enabling independent development and deployment of code.
As Rich Sharpes, Senior Director of Product at Red Hat, mentioned at Red Hat Summit ‘16: “today, speed = revenue”.
Microservices support growth: by allowing services to be scaled independently.
Depending on the traffic scenario, we can add a few instances here or remove a few instances there.
Microservices foster innovation: they enable experimentation and “fail-fast” to create the right products – and do so by enforcing agile, product-centered and self-enabled teams.
These features make microservices look good on paper – but what do they look like in production?
This screenshot has been taken from one of South America’s largest ecommerce production environments serving more than 3k services distributed over more than 10k containers in 7 datacenters.
Building a system composed of microservices effectively means building a fault tolerant, highly dynamic distributed system – and that‘s a complex thing to do.
Let‘s look at an important detail here: as you can see from the service instances colored in red, services are failing all the time (30). However, Dynatrace understands that none of these faulty services had an impact on any of the customer‘s applications (9).
Now, I’d like to present how Dynatrace can help you manage the complexities when designing and running microservices on OpenShift by discussing 3 important learnings.
In fact, microservices themselves can be fairly simple -- on the inside – however, complexity doesn’t vanish.
Instead, complexity shifts into the surrounding environment and the inter-communication between services.
We also say that microservices have lower inner complexity with relatively higher outer complexity in the connecting parts.
So, what is a microservices platform compose of? We need things like service discovery, configuration management, routing, load balancing, execution environments, such as Docker, messaging channels, but also deployment automation and monitoring are considered key capabilities of a microservices platform.If you’re using OpenShift, the complexity of building and running such an architecture are nicely abstracted by convenient tooling. Still, you’re going to build, ship and run your services on a significantly complex distributed software stack.
Essentialy, you use a PaaS because there’s no real sense in crafting your own platform. And in a clustered environment you also don’t really care about how your containers are scheduled – but that doesn’t mean that you should fly blind.
Drilling down to see some more detail shows that Dynatrace computes a topology-model of the entire system which reflects the real-time relations and dynamics of your applications, right down to your data centers, including any services, processes and containers, and hosts.
This is important for 2 reasons:
Customers have told us that they had no idea what their system actually looked like – until we showed them
Having the possibility to introspect a system at its various layers in detail and real time helps people in business, dev and ops make better decisions
With Dynatrace, all of this is auto discovered for you.
One design principle of microservices is to “do one thing and do one thing well”, which aids separation of concerns and composability. To remain composable, microservices demand robust APIs.
Imagine the desired scenario where your teams own separate microservices. How can you be sure that the resulting services interact as designed?
We can’t validate that your services behave as intended by their designers, but we make you see how your services are composed and how often and in which ways they interact in real time.
Here‘s another way to look at the same service.
BASELINING
What you can do in Dynatrace is…
In a highly distributed microservices environment, the old saying “the more moving parts, the higher the likelihood for failure” certainly holds true --
And since failures can happen any time, you have to become fault tolerant: you have to ensure that your application can tolerate a potentially high number of simultaneous failures without compromising customer experience. Just because microservices can be deployed independently (if designed correctly), it doesn’t mean that they fail independently.
Instead of presenting you uncorrelated incidents, we equipped Dynatrace with an artificial intelligence technology that enables you to answer these questions in a matter of seconds, all automatically with no manual configuration involved.
Let’s talk about about the role of the network: the migration from a monolithic to a to microservices-oriented architecture involves trading fast in-memory communication for slower inter-service communication across networks.
This can quickly become an issue if
services are chatty, or
When services are too fine-grained: the higher the degree of distribution, the more communication over the wire
What if the network infrastructure itself becomes a limiting factor?
BASELINING
Question: how would you be able to detect this problem if you relied on mere log analytics? Hardly at all.