MicroservicesTV Episode 15 – Evolution of Microservices, Part 3 (Extended Q&A)
Articles,  Blog

MicroservicesTV Episode 15 – Evolution of Microservices, Part 3 (Extended Q&A)


Thanks and welcome back to our third and final
installment from the PLoP Conference here. I’m back with Kyle Brown again to go ahead
and take some audience questions from the field here. So you guys can’t see them right now, but
we’ll go ahead and repeat the questions once they have them. And you know have some good conversation here
and see where it goes. So questions from the audience… Sure, so to make sure that we can hear the
question on the audio, what Ralph Johnson was just asking was if we can comment a little
bit on the people side of microservices; that we’ve covered a lot of the technical issues,
but in fact what we’ve seen that has been I’d say driving a lot of the adoption of microservices
have been people issues. Things like you know the adoption of DevOps,
the adoption of 2 pizza teams as you were talking about, and some of the other organizational
issues. So you want to start with that Rick and then
I’ll jump in? Yeah so I mean a lot of that ends up being
kind of going off of some of what I finished in our last session. Kind of where I stopped myself from going
off on the tangent into the woods at the beginning of our first session. You end up having a lot of that all coming
together, so you end up having these 2 pizza teams, in the same sized teams, you end up
having a lot of pair programming. Or a lot of, there’s a couple different terms
for it but a lot of the the kind of the T-level skills. Where you have everybody working across a
little bit of everything but in working together, they all become a little bit more educated,
so you end up having cross-functional teams that you end up having here as well. So you have the business integrated with the
technology teams, you have the support team there, you have the design teams there, and
so everybody is – they’re smaller, they’re more functional because everybody’s kinda
contributing what they’re doing and so getting to, getting your point of kind of moving throughout
the industry, everybody gains a little bit of skill while working with everybody else
much closer; as opposed to just doing their one thing, throwing it over the wall and then
moving around. It’s interesting in that I don’t think that
adopting microservices would absolutely require you to adopt Agile methods. But we’ve definitely seen that the two fit
together better than almost any other programming style we’ve seen. Because if you look at a lot of the things
that Ken Beck was advocating in Extreme Programming and that a lot of the other Agile Alliance
folks have been you know suggesting all these years. You know these fit to the idea of small teams. So pair programming, incremental testing,
with you know DevOps pipelines – all of these things are easier to do when you’re doing
it in a team of 5 or 10, than when you’re trying to figure out how to scale that up
to a team of 100. Now that’s not saying you can’t scale microservices
up to a team of 100… you can. But the way you do that is by building 10
10-person teams, as opposed to trying to build you know 1 50-person team, that then you run
into some of the you know old software engineering issues that we’ve known of for years, like
on Conway’s Law and you know some of the other problems that we’ve run into that Fred Brooks
originally wrote about. So I think that’s probably why there is such
a synergy there, because microservices allow you to only focus your attention on one business
problem at a time, it allows you to be more optimal in how you’re going to adopt some
of these agile methods and you don’t have to worry about some of the cultural and organizational
issues that come with scale in existing organizations. It’s not that agile doesn’t scale, the problem
is always how do we make it scale given these other factors that organizations are going
to place on you, like reporting structures and compensation structures and all the other
problems that make it difficult to build in place. And speaking from experience with a lot of
those same Agile practices, working on some previous middleware stacks that we had, it’s
much more fun as a developer to work on the microservices side of things and have a much
greater velocity, as opposed to working on a CI/CD stack that, you know what it’s generating
is a multi-gigabyte binary deployment. So I mean being able to have your instant
feedback from your integrated testing and iterative testing, that Kyle mentioned and
being able to work with the designer, get feedback, and keep going it… It’s just much more energetic as opposed to
the where the kind of typical client-server traditional JEE stack kind of lead us to. Which is just not as from again the people
standpoint a energetic, friendly work environment. Another thing that also I think plays into
this, that again goes back to some of the things we know about Agile Methods and you
know dating back to the original XP work is that one of the things that we’ve seen applies
very well to microservices-style projects is the concept of a “minimum viable product”. You know something that the Stanford Design
School guys originally thought up. And with that, it gives you the ability to
be able to demonstrate progress very quickly on, you know, specific functional aspects
of your application that you’re trying to show. And you know that just goes back to the very
old ideas that we’ve had since the dawn of the PC era, if anyone remembers Dan Bricklin’s
demo program. You know the idea of simply being able to
show progress quickly has had a lot of traction over the years and that’s one of the great
things about microservices is you’re not doing it in something that’s throw away. You’re showing progress quickly with a real
piece of functionality that can be built to production-level code. It’s just you’re doing it on something very
small and that allows you to then accumulate a number things over time. So let me first of all try to rephrase the
question and and make it so that the TV audience can understand it. The question was around as you were doing
some pattern mining for microservices and trying to discover some of those issues, what
you found is that there are a number of issues around, I’m simply going to call it the scalability
of microservices. What happens when you do reach that point
where you’ve got several dozen or a hundred microservices and they’re all changing at
different rates and you have to be able to manage all of them and release all of them
and you know handle all of that. Am I getting that right? Okay. So that is why I think we’ve seen such adoption
of a number of existing frameworks that encapsulate some of the patterns that we were already
talking about. But also it’s interesting if you go back and
read Martin’s paper on microservices. You’ll see that he had a very strong opinion
on one particular aspect of that, that I think sometimes gets lost. And his strong opinion was you should consider
versioning of your services to be an absolute last resort. Now the way you achieve that is actually there
is a pattern that we workshopped here at PLoP a number of years ago that Rob Dagno published
as part of his book, called a tolerant reader. And the tolerant reader is something that
was always very difficult to do in technologies before we had especially JSON and REST. Where essentially you build your clients in
such a way that if they’re getting sent extra information, they ignore it. And they’re only looking for specific pieces
of information that they know they need and if they’re getting sent something else, they
just pass it on or throw it away. Now that is key to really making versioning
less needed, because if you think about most the kinds of changes we make in versioning,
it’s additions. It’s you know we’re adding a field here, we’re
you know expanding the length of the field there, were doing that kind of thing. And if you can build specifically very tolerant
readers in your parsing of the information you’re getting back to where you’re looking
for only specific things and you’re ignoring everything else. It allows you to not eliminate, but reduce
the total amount of versioning you have to do. Now the other thing that you end up having
to do with scalability of microservices like this is you end up having to adopt a number
of these other patterns from the very beginning. You end up having to say that look all of
my microservices have to use service discovery, all of my microservices have to end up implementing
the circuit breaker pattern, all of my microservices have to follow a common DevOps pipeline structure. You can’t really let 1000 flowers bloom in
the basics of how the services interact with each other. The contracts between them have to be firm. Now outside those contracts, you can allow
a lot of variation in implementation. Yes I can implement this microservice with
Javascript and I can implement this microservice with Java, and this microservice with C++
or Go… But the contracts between them have to be
pretty well established and hold tight over time, so that you’re minimizing the total
amount of change that you know is actually gonna require you to create a new version
or to have to change the overall topology of your microservices application. And I think that question leads to another
point as far as some of the gotchas that are pains of microservices just in general. And so it’s not something where again a new
project or kind of moving into a new implementation of existing project is you know microservices-first,
let’s plan out all the hundred microservices, we need to implement them all, because that
goes back to the exact antithesis of what you just said… But we’ve both seen projects that try that! Fool me once! So I mean that’s where again, I mean that’s
kinda where a kind of a lot of the approach goes to the one of the heated topics of what
to do with when getting started with microservices. Whether you go with a full you know start
implementing everything as microservice or a monolith-first approach. And so that’s kind of some of that navigation
where it’s like “do you want to get it working to prove the you can do it?”, do you want
to deliver something that’s functional. Then yeah okay, go do the monolith-first approach
and as you start doing that kind of have a you know Strangler Pattern toddler there sitting
there starting to grow into this bigger piece, where you’re you know evolving your own monolith
and then starting to shave off some microservices as well. So that kind of touches on the SOA point as
well, where in Martin’s papers a lot of it is you know colloquially termed down into
“SOA done right” things like that. Where you see SOA as more of a service-adoption
pattern for external service adoption, whereas microservices as far as kind of inter-team
or intra-team service adoption. Uh huh. Yep. So you end up having the concept of SOA has
evolved into a much finer-grained API plus microservices, API gateway plus microservices
style pattern that ends up kind of evolving that into into the current state. And that gets into an interesting point that
is probably worth making about microservices. When we look at some of the decisions that
were made and some of the motivations that we had during the services-oriented architecture
period, if we can call that. One of the things that I think led us astray
in SOA is and I can even tell you where it came from. We, emerging from object oriented development
in the Enterprise, were always looking to build object libraries of reusable objects. Therefore we started building services. We were looking to build service libraries
of reusable services. And we spent a lot of time and effort in trying
to understand how to identify “well is this service gonna be reusable” and you know what’s
the effort you have to put in to make it work that way. That’s actually something that’s not necessarily
part of microservices. Microservices are not explicitly trying to
be reusable across an Enterprise. If it so happens that a microservice is reusable,
that’s fine, because the independence it has allows into make new scaling decisions and
you can deal with that and handle it as you need it. But it’s not something that requires a lot
of that upfront design, because the microservices themselves emerge from the domain concepts. And it may be that in my Banking domain that
I’m working in, I may have 2 different types of accounts that never touch each other. You know my mortgage accounts and my banking
accounts may be entirely different and I don’t need to come up with a single account representation
that covers both of them. But on the other hand, my customer representation
to where the same customer does have a mortgage account and banking account may be something
that is best shared but that’s something that can be discovered over time. It’s not something that necessarily requires
a big design upfront. I first of all one repeat the question. And that was coming from Caas and what you’re
saying is that it seems that with a lot of the microservices frameworks that we’re seeing
in a lot of the microservices applications you’re seeing written as frameworks, the applications
themselves become very heavyweight because it takes a lot of libraries that you have
to bring in to implement circuit breaker, to implement service discovery, or other things
like this. And that makes the individual processes not
so micro, it makes them rather heavyweight. And as a result could we instead look at a
separate option you know when you made the distinction between a soldier who has to carry
everything in to battle with him or a hipster where they only function in an urban environment
with the coffee shops. You know it’s like the old hipster meme that
you’ve seen about you know it’s a good thing I don’t have to hunt and kill my own food
because I do not know where gluten-free tacos live. Yeah. The point is is can you not put them directly
in the process, can you make it part of the environment? And I promise that Caas was not a paid endorser
of you know our particular project we’re working on. But one of the projects that IBM is actually
working on is a project we call Amalgam8. And one of the design principles we’ve taken
with Amalgam8 is that we use what are called sidecar processes. What sidecar processes allow us to do is it
allows us to be more language-neutral and language independent in the implementation
of some of these patterns, like service discovery and circuit breaker. And allows you to then have a much smaller
client library or client access method, where you can perhaps just do with HTTP into the
sidecar process. And what it requires then is that since it’s
a sidecar process, your Docker container or VM simply have to have an instance of that
process local to the process that’s actually providing a microservice. As you said it becomes part of the environment. And so it’s something very similar to you
know driving. Driving down here from Chicago today, I used
a lot of cruise control. So it’s like almost putting your microservices
on cruise control, when you can shift a lot of that outside externally like you mentioned. But you still need to you know know what you
need to do when stuff goes haywire, when you have an accident, when you have a back up,
things like that. So it’s again kind of absolving some of the
overhead that you would need, as far as you don’t necessarily want to kind of continue
the pattern of a recent implementation I’ve been working on where you add in each capability
– service discovery, okay there’s a server for that, you end up having a circuit breaker,
okay there’s a server for that, you end up having distributed tracing and logging there’s
a server for that. So you end up keep adding adding all these
different pieces in… It’s not that shocking… but you end up adding
all these different pieces in and it ends up being again like you said something that
you know pack a lot in there. When we generally I think by the time we’re
gonna be done our reference implementation we’re going to have 5 business level microservices
but there’s going to be 7 to 9 like what I call infrastructure microservices or like
what you’re saying those initial pieces. So you end up having that, but then you know
scaling that out where eventually the application levels can scale much higher and then you
end up having a kind of a linear or a pretty you know, almost logarithmic infrastructure-level
services while you can have exponential application level services. So in the the smaller functions it is it is
kind of again the first person going in, the first team adopting, in sense of making a
lot of the headway, and adopting that. But then there’s a lot of flexibility and
a lot of speed that other teams can pick up based off of all this other work as well. So Rebecca had just asked a question that
was multi-layered, but let’s try to unpack a couple of those layers. The first of them was under what situations
are microservices applicable or not applicable? And so that’s one question we can address. The second question is more to I think kind
of given that in different areas of your system have different rates of change, in the business,
what effect does that have on the applicability of the microservices or even I want to go
into the organization of the teams around the microservices, because especially when
you do have stable parts of the system, that has some interesting team dynamics we need
to talk about. So do you wanna maybe start on the applicable
and not applicable and then I can chime in. I mean again going back to where we started
it and some of the session, I mean there’s a lot there, that we’ve come through many
different phases of distributed computing, many different kind of just as much as we’ve
done the evolution of distributed computing originally, and evolution of integration and
integration patterns for a lot of that. And so I mean just like you said there’s a
there’s a lot of legacy that is very entangled and so that’s something where again you look
at what makes sense to and kind of going to the second-half of the question, that rate
of change. I mean when we’re looking at things where
again you’re generally not going to be breaking up your core banking applications and doing
that in microservices anytime soon. Just based off of a lot of that being centralized,
running on our highly-powered, transactionally-protected you know systems right now. But why would you need to change that when
a lot of that is you know you know pretty much working and has been for awhile. What you really need to change is those edge
systems, those systems of engagement that you end up pushing out into a lot of applications. Again what I’d mentioned back in the beginning
as far as the business reasons for microservices, delivering that overnight functionality to
your end user. Now when you kind of look at the call chain
of where that actually comes down to, you can kind of see lots of different engagement
or kind of exposures to the user. But that’ll eventually all trickle down into
sys… common applications here and there. And so what need to change… Just kind of the data backend and use the
user interface. And then now with the the advent of mobile
being able to push out different mobile applications, and going back to kinda Kyle’s points of the
DevOps pipelines, of having you know multivariate testing out there for A/B versions, where
right now when I bring up my phone, I have one version… same version of the application
but I have one experience with Uber. I’m with a friend and they have a different
experience of Uber in the same application, same version. So I mean so that’s kind of what what you
get there when you want to deliver you know that the highest possible, highest-satisfactory
user experience to the user but in the end, you don’t need to kind of be constantly reinventing
are busting up your credit card processing payment information. So I mean that’s that’s kind of the the level
of dissection we end up seeing a lot. Exactly and to echo that and to use some of
the terminology that you just used here. I think what we’ve seen is that Systems of
Record MAY benefit from microservices. But it’s the same question, you have to ask
about refactoring that System of Record into any set of new technologies. If it needs refactoring because it is difficult
to maintain and its rate of change is such that it requires significant, ongoing maintenance. Then yes, that’s probably one you should consider
thinking about refactoring because that’s the reason that it’s doing that. But on the other hand if it’s a stable system
that isn’t moving, there’s no need to refactor it, so there’s no need to consider microservices. But on the other hand, Systems of Engagement. We know that Systems of Engagement have extremely
rapid rates of change. Well that is the poster child for writing
microservices. Now the really interesting one and this is
one that we’ve played with and I have yet to really make my mind up about this is the
other type of system and that’s the System of Analytics. Where sometimes you know there’s a couple
of other names for it, you know Systems of Discovery. You know you think about the kind of thing
that what you’re doing is, you’re not building a website on top of something, you’re not
you know storing your transactional data, you’re looking back through your historical
data or you’re looking back at real time data and trying to make decisions from that. Systems of Insight is what they’re sometimes
called. That one ‘s challenging because a lot of the
technologies that you end up using to build Systems of Insight. You know, things like Hadoop, Apache Spark,
you know that are based on parallelism and the kind of scatter-gather kind of thing. To use another one of Bobby’s patterns. It’s sometimes difficult to figure out if
microservices would really be applicable to that. Sometimes I can see that I could go on writing
a common routine that I’m going to use a lot in Hadoop, I can maybe kind of see that but
it it gets difficult. It’s not as clear as it is in Systems of Engagement,
to where it totally makes sense in those cases. I think the jury is still out on that one. I think we’ll see some applicability but we
just haven’t yet been able to kind of work out where the edges are in those kinds of
systems. One other similar area that I’ve been working
with another client on, in a similar Systems of Insight, kind of in between that Systems
of Engagement and Systems of Insight layer is around business process management and
a lot of the process-oriented techniques that you have where again when you look at that
you have a lot of milestones or a lot of independent business function that are passed from team
to team the team in a somewhat orchestrated process. So that now you have teams kind of trying
to reverse orchestrate a lot of microservices to put together. And so where does… where deos the benefit
come out of that? Going back to the previous question, how much
overhead are you willing to accept to kind of break out of these kind of BPM platforms
and then build your own in microservices and orchestrate a lot of that. So there’s a lot there that we’re kind of
just getting into a lot of that a similar analytics slash process orchestration level
for that for the business, not necessarily for the IT automation level. Okay… so it’s an interesting question. But the question that Jason was just asking
was we know that there are certain companies in the Internet space, you know like Gilt
is a commonly-used example, Netflix obviously, you know even Amazon to some cases, that have
made a conscious architectural choice to pursue microservices as an architectural schema. But there are others like Facebook for one
and I believe you also gave the example of Etsy that have chosen to instead you know
embrace a more monolithic approach. And kind of you know what’s… what are the
tradeoffs in that. And what are the pros and cons in both approaches? And the interesting thing is I think that
one thing you have to think about when you’re trying to determine if for a particular domain,
if the microservices approach is going to be right for you is if you look at the number
of functional areas you have in your overall domain. I would say in the wider the number functional
areas you have, the more attractive a microservices approach becomes. Etsy is a good example of that. If you think about what Etsy does. They don’t have a lot of functional domains. It was pretty much – you wanna create your
own store, you publish your things into your catalog, and then you want to be able to take
your payments for it, for all the cufflinks and everything that your making out of pop
top cans and things like that. Okay, and by the way I have bought some things
from Etsy. They’re not all made out of pop top cans but
the thing is is that I think if you’re looking at something more like a Netflix to where
they actually do have a fairly large set of functional areas they cover or even Amazon,
which has an enormous set of functional areas, that they try to cover. That may suggest a better match for microservices
than… The other thing about Etsy too, they have
publicized very well that they a very strict and very robust DevOps culture. And they’ve been able to enforce that company-wide. And I think in cases where you may not be
able to enforce that you know across your team as tightly, that again microservices
may give you a way of building more pockets of that. Perhaps using something like the Strangler
Pattern. To where you can begin to adopt those kinds
of things instead of having to be as rigorous about it as like an Etsy has been. And I think what we ended up seeing as another
pattern that’s not foreign to a lot of enterprise implementation but a Center of Excellence
or Center of Competency. And whatever when it’s you know there’s a
small section of people and leaders that do it, and define success and achieve success
and then you know publish or roll that out internally and kind of run with that. I think you know from the Etsy point of view
I believe they major on PHP… I’m pretty sure…That’s something that they
were, which I’m fond of since that’s what I first started building websites in you know
back in high school, so I like that a lot. But I mean that’s something where again they
have a very strict DevOps culture, that they you know they’re very rigid in what they’re
doing, it’s you know this is what we do, it can be achieved here, we know it can, we’ve
done it before. You know just don’t pick up the next big thing
because it’s out there. Like think through the ramifications, think
through the teaming and all of that stuff. So when you have that control and you can
be successful, it absolutely makes sense. But when you end up having a lot of different
areas, like again Kyle mentioned travel companies, I’m working with you know pharmaceutical companies,
retail companies, all these different companies where you have again globally distributed
teams, very different business capabilities, different requirements where again you need… You know Python is great for you know analytics
and data streaming, but then you know NodeJS is better for some other reactive stuff and
things like that. Where you end up having these different different
things to do a lot of that, it tends to kind of put pressure or strain on that so when
the people that end up being able to define success, come to take the path of least resistance
and are still successful, that usually where it is kind of self fulfilling in that aspect. I completely agree with you and I think I
wanna end this by echoing a point that Rebecca was making with her question. It comes down to maturity. Look if your team already has a mature model
for being productive. You don’t necessarily have to look for another
silver bullet to make you’re team productive. Exactly. Yeah it’s this is the thing you want to do
if you sense that there’s a problem. Than on the other hand if you’re not having
a problem, you may not need to pursue it. And with that I think we’re.. Yep, we’re about out of tape and probably
out of power, so… That’ll be good for this week. So again signing off for the Q&A session from
the PLoP Conference here, I’m Rick Osowski and Kyle Brown. Thank you very much. See you again!

Leave a Reply

Your email address will not be published. Required fields are marked *