Practice English Speaking&Listening with: MicroservicesTV Episode 1 - Intro to microservices with Jason McGee, Part 1

Difficulty: 0

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

around it.

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.

The Description of MicroservicesTV Episode 1 - Intro to microservices with Jason McGee, Part 1