Hi. My name is Ralph Winzinger. I am a software architect and editor for InfoQ. I am here at QCon New York 2015 and I am here with Sylvia Isler. Sylvia, would you please introduce yourself to our readers and watchers?
Ralph's full question: You were talking about microservices and migrating to microservices, actually. Microservices is really a trend right now. For the last two years, I guess, everybody is talking about microservices and I think there are quite a few efforts to migrate to microservices, but I think it is not done the right way every time and maybe not for the right reason. So, in your opinion, what should be the primary goal one should focus on when migrating to microservices?
Microservices are an architectural technique. It is a tool that we have in our bag of tricks as software engineers and it is not necessarily a means to an end. If you have some bottleneck or if you have some set of algorithms that can be subdivided and provided as individual services to the consumers of those services, then it may make sense to decouple them from the monolith and deploy them as microservices. But if you have a monolithic architecture and you have not thought through how the components in that monolithic architecture are working together, the interfaces between them, then going to microservices without doing your homework and thinking through the data for all of your architecture, what the pain points are, the potential bottlenecks and the performance issues, then going to microservices may be a mistake.
Ralph: At least it is dangerous.
And dangerous, without you doing your homework and doing that thinking.
So there is a few ways to prepare. One is a sort of paradigm shift and a mind shift in terms of the engineering organization. So, if you have a team or n teams working on your monolithic system and you want to look to subdivide it into microservices, then you have to bring the team along. It is an educational exercise. It is about bringing the mindset of a team along and get them aligned and excited about any re-architecture or refactoring, including microservices.
Consider that if you have an amazing technology or an amazing process that you are about to impose on the organization and the organization does not believe in it or does not understand it or does not necessarily agree with the approach, then each process-oriented transformation, each technology transformation will fail. So, it is really important to bring the organization along towards any process or architectural change that you are looking to make.
Ralph: First of all, making the organization hungry for microservices and then introduce them.
Exactly. It is mindset change. It is the collective mind of the organization that has to be oriented towards microservices.
6. What do you think is harder: to change this mindset or to introduce the technology afterwards?
I think that, again, it gets back to if there is a good reason, if there is a pain point that needs to be solved and decomposing into microservices is an integral part of that solution, then it should not be that hard to change the mindset. But it has to presented and argued for just like any other thing.
Ralph's full question: This kind of migration to microservices is like a huge refactoring of an existing system, at least when you do not have a Greenfield approach and my experience is that there is never a budget for refactoring, for whatever reason. So, what would be the top three arguments or pain points to identify and to present to the management to get this huge budget that you need?
What I tend to do and what I have done in the past is just do it or do part of it and show it to management and make the arguments around that. I haven’t tried it the other way where you ask permission and make the case. I think you have to start by doing and demonstrating and proving not only to yourself and your team, but ultimately to the management and then, that proof point plus maybe a few strong elbows will get the budget that you need.
Ralph: So making baby steps and showing the improvement just to get the bigger budgets and to show that microservices can pay off really soon.
That is right.
Every application has bottlenecks and pain points, if you will. And often it is the case that putting an interface in front of it, extracting it from the system and deploying it is the right thing to do. I think that, as engineers, we need to constantly be looking at the bottlenecks in our system, the potential pain points and places where we can improve in the architecture and make the case in terms of the benefit to the system and, more importantly, to the customers that making those changes will provide.
Identifying the bottleneck, figuring out the best solution, the best way to solve the problem or the root cause of the bottleneck and then extracting it as a microservice, if that is the right thing to do.
In a monolith where you have a hierarchy of dependencies - in some cases it can be like a house of cards. If one of those dependencies fails, the monolith will fail, the whole executable has to be restarted. In the meantime, you are suffering downtime and your customers are suffering downtime. In microservices, one of the advantages, although you have a graph of dependencies which may be complex, if you engineer for recoverability and not necessarily trying to avoid failure, but being resilient enough so that your services can recover from failure, then that graph of dependencies may fail at some point, but your system as a whole has that resiliency or is designed to function as a component that has failed is being restarted or another instance is spinning up, etcetera.
Ralph: That sounds a little bit like the message behind the Reactive Manifesto.
Which I read and absorbed, yes - let it fail!
Yes, it is interesting. There is a school of thought that says that in microservices there should be no shared libraries. If there is duplicated code, so be it. However, there is a limit to that line of thinking in the sense that if you have a piece of code that does some set of computations or performs some function and you do not want a dependent library between the microservices so you might copy the code or you have two different implementations of the code. What if the two pieces of code have the same bug? Or if you want to put the same enhancement in both pieces of code? If you find yourself editing the code in multiple places, then it is time to make a library and it is time for those microservices to share that library. As usual, the answer is “It depends”. You have to take it on a case-by-case basis and try to be smart about it and kind of weigh shared libraries and interdependencies against the pain and error-prone practice of editing duplicate code in multiple places.
Ralph: What I at least seem to recognize as a pattern is that business functionality is not shared, but the functionality between the services – so something like the protocols or whatever – that is the part that might be shared. There are a lot of libraries from Netflix and Twitter which can provide certain support on that level. So, that is maybe the stuff that can be shared in microservices, I guess.
Yes, the kind of underlying, operational libraries. Certainly.
I do not want to turn this into a marketing session for VMTurbo, but VMTurbo recognizes that having a large number of entities in your environment and trying to ensure that they have the right number of resources to run based on the drawing from the underlying supply of the infrastructure is what VMTurbo does. It is inherently a very difficult problem as you pointed out for a human to solve, or even for a collection of humans to solve and that is what our software does. So, that is my answer.
Ralph: Keep our systems up and running, hopefully. Say we have the chance to start a greenfield approach, would you recommend to start with microservices right from the beginning or would you rather recommend to structure a monolith so it can be broken up in parts later?
I think that if you ask an architectural purist, you may get a different answer than what I am about to say. I think that first and foremost when we are developing a new product in a greenfield, the point should be to develop a product that works and satisfies the needs of the customers. So, there is no point in over-optimizing if you do not have a customer base who is actually going to use your product and put demands on the product that a monolith cannot provide, you know. Get the product done, make sure it works and then start to decompose, if necessary.
Ralph: So it is just like Randy talked about yesterday. It is exploration and execution and as last step scaling up, if necessary.
Yes. Exactly. And he also says that if you are in levels deep into the development of a product, then you do not have anything to optimize. That means you really over-engineered it in the first place.
Ralph: That is right. Thank you very much for the interview. It was very interesting and it was very much fun.
Thank you for having me.
Ralph: Have fun at QCon!
I will. Thanks.