Hi, I'm Rick Osowski, Product Manager at IBM Cloud and host of microservicesTV. Join me
this week as we have Jason McGee, VP & CTO of Cloud Foundation Services here at IBM.
This week we discuss intro to microservices, and what all the fuss is about.
Hello and welcome to the first installment of microservices TV. I have Jason McGee here
with me today to kick it off. Over the course of the series will be talking about how to
get started with microservices, what they mean technically, how to kind of start each
of each of the different individual components. But today will just kind of have a high level
discussion on what microservices are, why are they important, and where to go from there.
So Jason I'll let you introduce yourself and then we can jump into the discussion.
Thanks, Rick. I'm Jason McGee and I'm Vice President and CTO for Cloud Foundation Services
at IBM. So I have responsibility for all the things were doing around containers and microservices.
Awesome. And so what exactly, how would you, to the uninitiated, how would you describe
microservices? What exactly are they solving or what's the kind of technology behind them?
Yeah one of the things that I think is interesting about microservices is we often talk about
them technology. But really the problem that they're solving is a people problem. It's
about how do organizations and development teams build applications with more agility,
with more speed.
Historically we've built applications by you know assembling large teams that build kind
of large monolithic applications that did all of the things that the business function
required in one large application. And the challenge of that model has been you know
as you evolve, as you change, it's very hard to kind of move that entire application through
its pipeline and every time you make a change have to test the entire thing, you have to
scale the whole thing, you have this big team to coordinate. So microservices is really
about how do you break things apart, in to kind of independent units that can be developed
by small teams, independently of the other components and therefore allow everyone to
go a lot faster in how they're building those apps.
So it's really about kind of taking our traditional infrastructure, traditional IT applications
and making them smaller and faster so that we can be more, I guess you'd say responsive,
to kind of the market needs. Kind of just move faster through, throughout your development.
Yeah I think smaller in the sense of more focused and purposed like you know you want
to kind of break your application down into a set of parts that do one thing do it well.
I'm have kind of limited scope or bounded scope about what they do and by doing that
yes, you get the advantage of speed in the sense that, if I need to update that I can
just update and deploy that one function without impacting everything else. But it also gives
you some other benefits like improved resiliency because failures are isolated within individual
components, improved scalability because you can scale different parts of the application
independently of each other -- you don't have to figure out how to scale the entire application.
So there's a lot of other benefits that you get by following this kind of architectural
Okay, you mentioned do one thing and do it well can you expand on that a little bit?
Because that's something where we've had the notion of services for a while and I mean
services kind of end up growing or you kind of have services or kind of service affects
by a side effect. So what does that mean in microservices to kind of do one thing?
Yeah, I mean I think a lot of times people all talk about microservices and they get
hung up on the micro word you know. Is there a size limit or cap where this thing is no
longer a microservice? And I actually don't think the size is that important in the grand
scheme of things. I think it's more about can you kind of draw a line around it that
says this function makes sense on its own? Right? It does it does something that's well
defined. And has a natural boundary, because part of what makes microservices work is clear
well defined interfaces between different components of the system. And so you have
to think about you know if you think about online video system you might have a catalog
of videos. You have a recommendation service that's kind of recommending things and you
have a search service. Each of those functions when wired together makes the entire application
or site but each of those pieces make sense on their own. And I know it searches I know
how what kind of API a search function provides and what data I need to bring into it. So
that that kind of micro dimension is really about thinking about how to decompose applications
into these loosely coupled relatively independent components, that can then evolve on their
So with that the notion of the loosely coupling and having a lot more smaller components ther
seems to be a need to have some sort of a management layer, kind of so that you're not
you can't obviously pay attention to three thousand kind of containers or three thousand
microservices, so are we seeing anything around there as far as being able to manage these
kind of either at scale or just kind of just automatically?
Well first let's acknowledge the problem, which is that there's always a trade off.
And certainly in computer science and IT, there's often trade offs and the trade off
I think you're making with microservices is a more agile more responsive development process.
But a more complex management problem. Right, you go from having let's say twenty instances
of a large monolithic application to like there's real world examples where companies
have taken existing application and re factored it into three hundred microservices. And each
of those three hundred micro services is clustered into multiple instances with load balancers
in front of them, so you wind up with literally thousands of components running. You have
a much more complex operational model. That is the result of these decisions that gave
you the result of resiliency, scalability, and agility that you're looking. And because
you have a more complex operation model, yes you need management you need management tools
and environments that help you deal with that, help you keep everything up, know what's going
on, replace things when they fail, you know understand where where problems exist or whether
things are performing poorly, so there's absolutely a strong kinda need for a management environment
So the the need for that management environments, I mean do we have anything today inside of
IBM that we're working on to kind of help our customers get to that point?
Yeah, absolutely so I think if you look at that trends in the industry a lot of people
who've been early adopters of microservices have built management tools or frameworks
themselves to help them with this problem. So part of what they had to do is figure out
how they find each other, how do I deploy them, how do I update them. What we've started
to do in IBM through things like the IBM Container service, through Bluemix, through things like
Active Deploy which is also a service on Bluemix. Some early work we're doing around service
discovery and proxy functions is start to provide those kind of fabric components that
you need to build an microservices app as services themselves. So as an application
developer building application using microservices I don't have to figure out how to stand up
all the management infrastructure to make that work, I can leverage services from the
cloud to do that for me and just focus on here is the services I want to go build.
And that's where we're going to cut it for today. Join us next week as have the second
half of this conversation with Jason and wrap up this first episode. See you then.