Q&A
Q&A with Miguel Castro: Demystifying Microservice Architecture
The longtime Microsoft MVP first defines microservices, 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 definitely bring many benefits to the table that traditional monolithic architectures can't, there's no use adopting them if you don't know precisely what they are, what they look like, when they can help -- when they definitely won't.
Miguel Castro, a longtime Microsoft MVP with decades of experience as a developer and architect, wants to take the mystery out of microservices, so organizations can start using them more intelligently. Castro will lead a session at next month's Live! 360 conference, taking place in Orlando, Fla., called "Demystifying Microservice Architecture." There, he'll cover everything developers need to undestand about microservices architecture, from core characteristics to approaches to whether microserices even make sense for your particular organization to use.
We caught up with Castro recently to get a preview of his upcoming session.
VisualStudioMagazine: Not to give too much of your session away, but what's the consensus definition of "microservices"? Is there a consensus to begin with?
Castro: That's one of the problems. I haven't found a real consistent consensus. The most common "lowest common denominator" is along the lines of autonomous units of responsibility that are individually maintainable, deployable and upgradable, all the while being as fault-tolerant as possible. The reality of all this is, of course, in the implementation differences and can vary greatly. Something always gets sacrificed in the interest of something else. Think of that famous software triangle: You can have it fast, good or cheap -- pick two.
"To me, microservices are what SOA should have been to begin with, and perhaps what it was intended 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 incorrectly."
Miguel Castro, President, Melvicorp LLC
What's the biggest misconception that IT folks and developers have about microservices architecture?
That you must use Docker and/or Kubernetes or you're doing it wrong. Microservices seems to have taken the arrogant nature of some to a whole new level. Don't get me wrong, they're both good products. But make no mistake, products like that require resources that know enough about them. I, for example, am not such a resource cause I have not worked with either of them enough.
Also, I believe that it's bad to take the approach that if I'm not incorporating every little characteristic (which I will discuss in the session) of microservices, I will fail. That's not true at all.
What's the biggest benefit of incorporating microservices design into your architecture?
Being put in a position of having to properly design and decompose your system is the largest benefit -- something we should have been doing since SOA [service-oriented architecture] started to gain traction, but havent. We've all been guilty of it. A solid service breakdown is the most important part, I believe. You can discuss all the other characteristics until the cows come home but if you have a bad service breakdown, not much else is going to fix that.
Are there any scenarios where microservices are definitely not the answer? Any potential pitfalls?
There always is. Microservices make your system have many more moving parts and take time to develop the more ancillary characteristics you give them. They can definitely drag out budget and time constraints on a system. Not to mention, in most cases when you introduce third-party tech into the mix (again, Docker, Kubernetes, etc), you will need resources that are well familiar with them. Not every shop can do it, and diving into too much head-first becomes its own pitfall.
That's why I truly believe you should adhere to what I describe in the answer above first because it is 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 to a system and many shops just need to get the job done very quickly. At the same time, there are systems that are done monolithic and not that bad. Too many labels are carrying a negative stigma and they really shouldn't. But everyone wants to be one of the "cool kids" today.
What's one thing you wish developers knew about microservices before adopting them themselves?
That they're not going to be the end-all to fix a bad system with improperly designed services. The term "lipstick on a pig" comes to mind.
Silly question, but can microservices get even more "micro"? Where does software architecture go next?
It's not a silly question at all. I fear that there are some that will attempt just that. To me, microservices are what SOA should have been to begin with, and perhaps what it was intended 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 incorrectly. So what's next? Nanoservices? Quantumservices? That's what I'm afraid of. Changing the name of something does not mean radically changing its intent.
I think it's important to understand all the characteristics to a design that something like microservices (and its architeture) are bringing to the table and mold it to what will work for your scenario and your shop (with its resources). People need to concentrate less on what things are called because that takes their focus away from what the intent should be. An example is the very prefix "micro." Because services should be isolated and kept to solving one problem (if possible), doesn't mean they should only contain one function. But there are some that believe they should simply because we're calling then "micro" services.
I think many shops need to look at the fundamentals of an application's architecture because that's where they should go next. But unfortunately, you can't slow technology down. It will always be further ahead of where most shops are and want to be. It's not an easy problem to solve and, honestly, one that I'm not sure is 100 percent solvable for lots of places. I think a lot shops can benefit from concentrating on, "What tech I can use to solve what I need my system to do (for me and my customers)," and not so much on squeezing new technology into what simply may not be appropriate and realistic for them.