Source:- itproportal.com
Microservices – a legitimate trend or just hype?
Undoubtedly microservices are part of a legitimate trend, they are a specific instance of a more general trend towards making IT systems more modular and independent. As a consequence of modularisation, there is also a desire within IT to miniaturise components – in essence, building applications with less code and less functionality. Historically, system components would be around for years. However, due to the nature of microservices they now only exist for a very short amount of time – many of them might only have a life span of microseconds or minutes. So when we look at the bigger picture, we can say that the deployment of microservices is very much in line with a wider IT trend.
Doesn’t microservices lead to greater complexity?
In short yes, but let’s first understand why there is a drive towards modularity and microservices in the first place. The reason for the drive is because it was believed that the more modular the system, the more easily DevOps teams could change the system to evolving business requirements. Ultimately, a team only needs to make local changes, without having to worry too much about what’s occurring in the rest of the system. Even from a performance and execution perspective, the fact that you’ve got so many different pieces makes it is easier to fit them into all kinds of architectures.
If your business decides to move a lot of infrastructure to the cloud, you have a lot more freedom when deciding which components remain in-house and which are taken to the cloud, or how you want to distribute those components over various cloud architectures. As opposed to managing a relatively monolithic system, where you will have far more constraints. There are a number of contributing factors as to why enterprises have moved to a microservices environment, but, in many respects, it comes down to gaining more agility and flexibility in regard to development and infrastructure.
However, there is no free lunch. The more agility you build into the system and the easier you make it to develop the system, change the system or distribute it architecturally, the more complex it becomes. And when I talk about complexity, I mean something quite precise…You effectively increase the entropy of the system design in a very real sense. When you have a system that is built out of a few monolithic parts, it’s possible to infer the state of the system as a whole from a few vantage points. But, if you’ve got lots of independent parts that are working in sync, but loosely coupled together, it becomes harder to predict the state of the system from a few snapshots – you have to look at almost all of the components to be able to see what’s happening end-to-end and acquire an accurate picture.
The consequences of an entropic system
The move to modularisation increases the entropy of the system. When you have a high entropy system every data point contains a lot of information, where as in the case of low entropy system many of the data points give you very little information. So we have bought this greater agility at the cost of a more difficult task of managing the systems. The other side effect of this is that many of the traditional monitoring tools pre-supposed a low entropy world, so they are not equipped to deal with high entropy systems.
Without doubt there is a lot of complexity within a microservices architecture, nobody claims that microservices makes things simpler for development and operations teams. However, the complexity is manageable.
So how does AIOps fit within microservices?
Firstly, enterprises use big data platforms to gather data points which is fine up to a point as you absolutely need some place to put all of this information, unfortunately for many enterprises they believe that’s the end of the story – we’ve got all the data and can access the data, job done. Of course all you’ve really done is assemble data into a big haystack, now you need to start looking for the needle. And this is where AIOps comes into play.
The basic premise here is that there are patterns and events which disrupt the normal end-to-end behaviour of the system – but we still need to figure out what the cause of disruptions are to fix whatever is ailing the system. Because of the complexity and high entropy of the system, seeing those patterns and being able to analyse those patterns simply exceeds the capabilities of human operators. Yes, there may be a mathematical curve which describes what’s going on under the hood, but it is so complex human beings are not able to come up with the equation to make sense of that curve and hence it is very difficult for them to figure out how to deal with it.
AIOps enables enterprises to work with the data that is being collected in large databases and see that a curve exists, and then come up with the equation that describes the curve. AIOps processes data and then has the capacity to see patterns and provide an analytical solution that human operators can use to solve problems.
What about the cloud and microservices?
For microservices in general, things work a lot better if you have automated orchestration. The configuration of any orchestration engine should be in response to a specific business or technical requirement. In this role, the AIOps technology basically informs that business situation. Ideally, the AIOps technology allows the enterprise to rapidly see the pattern, do the analysis, come up with the solution, which is then fed to the orchestration engine.
In an IT environment where applications are running and orchestration engines are manipulating the stack while applications are executing, we have a lot of activity which in turn results in massive complexity. In this instance the AIOps capability needs to view the IT environment in its entirety, which will include the impact of the orchestration engine, and this is true whether the engine sits in the cloud or not.
Cloud is an important economic and architectural development, but it does make life harder for people trying to manage the environment as information is more difficult to extract. However, the cloud doesn’t fundamentally alter the role AIOps plays in the support of IT systems.
What about traditionalists and microservices?
With every major technology wave there are sceptics and indeed their scepticism has been proven right a number of times. Not all technology waves have borne fruit. I think in this case they’re wrong, if you look specifically at microservices it’s a trend in terms of packaging technology, but it is a fact that it is part of a longer-term trend in how technology is being deployed.
Having said, what positive role do the sceptics play? There’s certainly little attention given by most DevOps teams to management. If the sceptic is wagging its finger highlighting the need for assurance, requesting more monitoring and understanding of root cause problems, then it plays a fundamental role in not just keeping things honest but ensuring that microservice projects are a success – both in terms of delivering functionality and economic sustainability. If you don’t take the cost of management into account early on, you’re going to have a very distorted picture of what the economics of the situation are.
Traditionalists tend to work against the trend and deploy new technologies exclusively for new applications. However, a lot of the value from these new technologies can come through re-engineering existing applications, because in many cases it was the problems inherent in existing applications which brought about these new technologies. So what ends up happening is that new applications are built, but the old applications which the new solutions were supposed to replace continue to limp along and don’t deliver good customer service.
How might microservices help AIOps evolve?
I think microservices will underscore the necessity of deploying AIOps. There is not even an option for a community of human operators to manage new systems. You need AIOps to ensure that microservices transitions from leading edge technology to being mainstream. For the broader market, microservices will help legitimise AIOps.
With regard to AIOps itself, the kind of analysis one needs to understand causality in a microservice setting is an analysis which makes heavy demands on topology or graphs, because you’re looking at a whole series of components that have all sorts of complex changing connections. A lot of the mystery that needs to be unravelled is what is the causal path that takes place from one microservice to another, what are the connections between the microservices?
In theory AIOps takes into account topological analysis, and many vendors like Moogsoft have developed a number of interesting algorithms to deal with topology, but more work needs to be done. So I think we will see topological, graph-based analytics become one of the central pieces of AIOps. It’s not that AIOps has not given attention to topology, but I think that topology will move to centre stage in order to cope with the particular kind of complexity that microservices bring to the table.
