Return to site

MicroServices - Build on System Models

Use system models to define components & behavior

MicroServices. All the rage these days. (Allegedly) in use by everyone, everywhere, all-the-time.

In reality, not so much, but still powerful and interesting. And the future, if we can all make them work, and more importantly, make them manageable, monitor-able, tunable, and troubleshoot-able. Unfortunately all of those are pretty darn difficult today.

MicroServices are difficult for a variety of reasons which you can read about elsewhere, but their proliferation, dynamic nature, and contribution to the general complexity of systems does not help.

Many systems are complicated, but using MicroServices usually forces them across the invisible line into complex systems. The difference is that complicated systems have lots of moving parts, but their dynamics, and especially failure modes, are well-understood. Complex systems are so complicated with so many (often circular) dependencies and dynamics that they and their failure modes cannot be well-understood. Complex systems often defy analysis, have unknown variables, and are non-deterministic. Great article on this: 18 Truths of The Long Fail of Complexity.

So real MicroService-based systems are often complex, and fail in unpredictable ways, especially when using traditional programming paradigms and common mistakes like long timeouts. Most non-trivial systems today are really hybrids, with a mix of traditional larger PHP, Java, or Python-based web apps, connected to Docker, Serverless, or AWS Lambda-like services for various parts o their functionality.

What to do ?

First, build a model of this, ah, mess. A model of every component, part, configuration, and element of the system, including all the infrastructure, the services, micro-services, Docker containers, serverless services, and Lambda stuff. With all the instances and their configurations, auto-scaling, load-balancing, etc. Then add in the configurations of all the apps, databases, web servers, etc. so everything is all in one place

Then you can use this model to document, visualize, tune, and importantly, troubleshoot the system.

How to do build such a model?

We use TOSCA.

Yes, it’s an Opera about love in Rome, but it’s also TOSCA, the Topology & Orchestration Specification for Cloud Applications, from the OASIS standards body. TOSCA is similar to AWS Cloud Formation, but far more powerful and extensible, partly because it also includes orchestration, relationships, and much more.

We think TOSCA is the way to model cloud infrastructure, and also the applications built on clouds (or even physical servers). TOSCA is fairly complex with several major parts for modeling, relationships, orchestration, and more, but this is exactly what makes is great for our purposes of modeling and managing the world’s IT systems.

In addition, we’ve extended TOSCA to include and drive building and configuration of the rest of the stack, such as Linux OS, Web Servers, MySQL, and everything else. This results in a full model of the entire system, which can then be used for management, modeling, automation, tuning, troubleshooting, and much more.

Our OpsStack platform does full-stack system modeling, with full Forward, Reverse, and Change engineering of real systems through their whole life-cycle. In particular, we want to know all the pieces and parts, and everything about them, including and especially their relationships. From this we can model their dynamics and dependencies.

And from that, we can drive Troubleshooting Facts and AI-Based Rule Engines, latency and clustering alerting, automation, auto-healing and the many more things that OpsStack does.

The model is your friend for MicroServices, for monitoring & management, tuning & troubleshooting.

See the TOSCA Opera if you’d like, but get a TOSCA model today.