Questions and answers
Q&A with Miguel Castro: Demystifying Microservices Architecture
Microsoft’s longtime MVP first defines microservices and then explains the biggest misconception about them, typical benefits, and when they’re not the answer.
There’s a lot of buzz around “microservices” right now, but not a lot of clarity. While microservices certainly provide many benefits that traditional monolithic architectures cannot, there’s no point adopting them if you don’t know exactly what they are, what they look like, when they can help – when. they certainly won’t. .
Miguel Castro, a longtime Microsoft MVP with decades of experience as a developer and architect, wants to solve the mystery of microservices, so organizations can start using them smarter. Castro will host a session at Live! 360 conference, held in Orlando, Florida, titled “Demystifying Microservice Architecture”. There, it will cover everything developers need to understand about microservices architecture, from basic features to approaches to whether microseries even make sense for your particular organization to use.
We recently caught up with Castro to get a preview of his next session.
VisualStudioMagazine: Don’t over reveal your session, but what is the consensus definition of “microservices”? Is there a consensus to start?
Castr: This is one of the problems. I have not found a real coherent consensus. The most common “lowest common denominator” is for self-contained units of responsibility that are individually maintainable, deployable and scalable, while being as fault-tolerant as possible. The reality of all this of course lies in the differences in implementation and can vary widely. Something is always sacrificed for the sake of something else. Think about that famous software triangle: you can have it fast, good or cheap – choose two.
“To me, microservices is what SOA should have started out with, and maybe what it was meant to be. But we seem to be in a business where labels and euphomisms carry a lot of weight. Call something. by a “cooler” name and people want to jump on it, even mistakenly. ”
Miguel Castro, President, Melvicorp LLC
What’s the biggest misconception that IT people and developers have about microservices architecture?
Whether you need to use Docker and / or Kubernetes or you’re doing it wrong. Microservices seem to have taken the arrogant nature of some to a whole new level. Make no mistake, they are both great products. But make no mistake, such products require resources who know enough about them. I, for example, am not such a resource because I have not worked enough with one or the other.
Also, I think it’s bad to take the approach that if I don’t incorporate all the little features (which I’ll discuss in the session) of microservices, I’ll fail. This is not true at all.
What is the biggest benefit of integrating microservice design into your architecture?
Being put in the position of having to properly design and decompose your system is the biggest benefit – something we should have done from SOA. [service-oriented architecture] started to gain ground, but not. We have all been guilty of it. A solid service outage is the most important part, I believe. You can discuss all the other features until the cows come home, but if you have a bad service outage, not much else can fix it.
Are there any scenarios where microservices are definitely not the answer? Potential pitfalls?
There always is. Microservices make your system have a lot more moving parts and take time to develop the more auxiliary characteristics you give them. They can certainly drag budget and time constraints on a system. Not to mention that in most cases, when you bring third-party technologies into the mix (again, Docker, Kubernetes, etc.), you’ll need resources who are familiar with them. Not all stores can do this, and diving too head-first becomes its own trap.
This is why I really believe that you should first adhere to what I describe in the answer above, because these are the roots of the tree (and you know what Mr. Miyagi said). Keep in mind that there are many factors that dictate the approach taken for a system, and many shops just need to get the job done really quickly. At the same time, there are systems that are made monolithic and not that bad. Too many labels carry a negative stigma and they really shouldn’t. But everyone wants to be one of today’s “cool kids”.
What is one thing you would like developers to know about microservices before they adopt them on their own?
That they will not be the end to fix a bad system with badly designed services. The term “lipstick on a pig” comes to mind.
Silly question, but can microservices become even more “micro”? Where does the software architecture go next?
This is not a silly question at all. I’m afraid there are some who will try just that. To me, microservices is what SOA should have started out with, and maybe what it was meant to be. But we seem to be in a business where labels and euphomisms carry a lot of weight. Call something by a “cooler” name and people want to jump on it, even if it’s incorrect. So what’s the next step? Nanoservices? Quantum services? This is what I’m afraid of. Changing the name of something does not mean radically changing its intention.
I think it’s important to understand all the characteristics of a design that something like microservices (and its architecture) brings to the table and model it on what will work for your scenario and your store (with its resources). . People need to focus less on what is called things because it distracts their attention from what the intention should be. An example is the same prefix “micro”. Because services should be isolated and limited to solving a problem (if possible), that doesn’t mean they should only contain one function. But there are some who think they should do it just because we then call “micro” services.
I think a lot of stores need to look at the fundamentals of app architecture because that’s where they should go next. But unfortunately, you can’t slow down the technology. It will always be further ahead than where most stores are located and want to be. This is not an easy problem to solve, and honestly one that I am not sure can be 100 percent solved for many places. I think a lot of stores can benefit from focusing on “What technology can I use to solve what I need my system to do (for me and my customers)” and not so much on integrating new technologies into which is simply not appropriate and realistic for them.
Gladys Rama (@ GladysRama3) is the publisher of Redmondmag.com, RCPmag.com and AWSInsider.net, and the editorial director of Converge360.