Coming to you from the wonderful city of
Chicago, the city that Studs Terkel often
referred to as "Chicago," I'm Bob Rhubart
with the Oracle Developer Community, and
my guest is Vijay Tatkar. Vijay, how are you this morning?
Fine, thank you.
Tell me about the session you're presenting.
What are you going to be talking about?
I'm going to be talking about two different trends that are coming today.
One is microservices, which is a new architectural style
that is gaining a lot more traction in the last couple of years,
and the other is systems management and how how these two
can help each other out.
I've been in the developer business for close to thirty
years now, and I have seen several trends
come and go,
from the 80s when when we actually had structured programming and modular
design and all those fun things, and
in the 90s when we did object-oriented
programming, RAD, if you remember, rapid application development,
rational style of programming.
Around the 90s was when some of the concepts around continuous
integration started coming in, as well.
Around the early 2000s we had more web development.
We had Web 1.0, Web 2.0 style of programming.
That's when continuous integration, agile, and scrum started picking up.
Scrum actually in the late 90s.
So all of these trends march towards a goal,
as we are doing more web,  as we are doing more devices,
as we are moving to services from
a product or a product suite,
we are moving to an architectural style that
requires faster deployment, faster builds,
faster turnarounds of all these things.
So it's just not possible anymore to write things in a monolithic style for
newer styles of applications, at least,
right?
So if you look at, for example,
the granddaddy of microservices is Netflix, right?
They were the earliest adopters, if you will.
They tried monolithic application and it
kind of fell over because they have to
support all the TVs in the world, all the devices in the world, all the phones,
so in hundreds of devices, over 200 devices is what they claimed.
It became hard for them to keep a monolithic application going,
so they started breaking it down into smaller and smaller pieces,
and as the microservices trend was evolving they got onto that train.
So microservices is an architectural style where you have
applications that are built out of components,
of loosely coupled services, in that sense.
So the idea is, each of these loosely coupled services
is self-contained and it has very light
protocols.
So they should be able to stand up by themselves
and not interfere with other things.
So that makes it easy.
You can have a small team then, instead of
having larger teams that are delivering product suites which need a
waterfall style of model for delivering, right?
Those are still popular, don't get me wrong.
The reason I talked about the
trends was,
many of the old trends, if we call them old,
are still there in the application, right?
People still do object-oriented programming.
People still do RAD programming, right?
So those trends are not necessarily going to go away.
The large majority of applications today
are still very much in the monolithic mold.
And even though the newer applications are...
you know, the reason they are moving is because of
agility of deployment and scalability, which are the two big reasons.
The classic applications are still very scalable.
They still deliver.
The Oracle Database is very scalable.
It still has many tens of thousands of customers.
And we managed to satisfy them quite well.
However, when you are starting to
look at a programming style or
applications that have demands on multiple devices,
it gets hard to build applications that are monolithic that way.
If you have hundreds of devices that you have to respond to,
you can't be releasing these monolithic applications every day.
That's just not the way you do it.
That's where the microservices style comes in.
It's that whole idea.
The architecture behind it has converged with other ideas
that are also meeting to deliver to the same requirement now.
With DevOps you know you have
developers and operations being put together.
With continuous and integration continuous deployment
the idea is you can put out releases, instead of on an
18-month cycle now you
can do them very frequently.
Many of us do once a month.
In fact many cloud applications do it
much more frequently than that.
So this is the kind of velocity or speed of application development
that was not possible before.
Along with this goes the style of doing agile or scrum
where you are trying to control the processes in a different way
than in the waterfall model.
So all of these trends are now coming together
so that it's not just microservices by itself.
It's microservices plus DevOps plus agile plus scrum plus containers.
You need a delivery platform that's  equally lightweight.
So the containers are are a nice way of looking at it as well.
So all these trends are coming together to deliver to the new
style of services or to the new style of
demands that people have in the field.
The other thing that we see from our side is,
so I'm the product manager for Oracle Management Cloud.
We do, classically, the systems management kind of things.
It used to be the domain of the Ops guys.
They do the network operating center, the security operating system, those guys.
Developers never bothered about that.
That's somebody else's problem, right?
What's happening with DevOps is these two now are merging together.
It's no longer just "you take care of deployment, I'll take care of development."
Because what's happening is that as developers are developing fast,
the ops guys have to keep up with that
pace.
They can't say "I have my 129 rules"
before you can actually deploy.
The developers are going, "but you know I'm releasing twice a day."
"You can't possibly apply 129 the rules to my release process."
With the convergence of this we are seeing that
the things that are useful for ops, like systems management,
are things that could be useful for the development side as well.
I'll give an example.
We have multi-tier architectures that we can find topologies
for quite nicely on the system side.
So systems is used to having multi-tier applications,
where you are looking at end-user apps interacting with
application servers, with databases,
and on the infrastructure side with
hosts, with networking,
with storage, with containers, things like that.
Understanding the whole topology from an application
and infrastructure point of view is a challenge
that systems guys have been meeting.
This is something that would help the microservices folks as well.
Because in the new style of microservices,
now you have componentized yourself.
Essentially you have taken taken apart many of these
components and now you have the same
issues, you have the same challenges of
latency, not understanding the whole  the whole picture.
So the whole topology picture is something
that you need to understand as well.
So these two things need to now converge together,
and we think that there is plenty that we can bring
to the table through systems management
tools that will help microservices application developers.
Given that we're talking about the convergence of these things,
microservices, DevOps, containers, and so on.
of course, everything works perfectly all the time, right?
Oh yeah, course!
One of the advantages of doing microservices,
now you have all the componentization that happens.
So you have different teams, smaller teams,
that work on their own terms.
They can pick and choose the components they want,
the framework that they want.
Not everyone uses an Oracle database.
Some, the ones who are looking at timeline data,
may prefer Cassandra.
Those who are looking at graphical interfaces may use Neo4J, for example.
And they are free to make their choices.
That's the beauty of it.
Each one of these groups is making their choices,
which is great for development.
But when you start looking on the deployment side,
now all of a sudden instead of having a single database to worry about,
now you have all these different databases
that are now part of your deployment picture.
So it's a much more complex picture on the production side.
Whereas the ease of development has improved drastically,
you also made the production side, the data center, much more complex.
What it means is each of these components can generate their own logs,
their own alerts, their own performance data.
Who puts it together?
How do we know how to troubleshoot in all of this?
How do we know if our capacity planning folks are doing the right things?
So these are problems that are emerging from this,
from the huge amount of data that comes out.
Our goal on the system side is to look at all of this data and see how we can unify it.
So all the data that comes from each of these individual microservice components,
plus the data that comes from  infrastructure,
plus the data that comes from your VM
containers,
from not just networking but VM containers,
from Kubernetes, from Docker and things like that,
we put it all together in a common data platform,
and the Oracle Management Cloud then takes all of that data
and runs machine learning algorithms.
Because it's no longer humanly possible to track everything.
When I talk to customers we are seeing that data centers are generating
billions of log records every day.
Not something that humans can actually do quite well.
We tried to put them in Excel spreadsheets, but the reality of the matter
is that in most data centers only about 6% of the alerts are looked at.
Six precent!
The other 94 percent get dropped.
Unless there is a meltdown of some kind, when there is a meltdown,
the system administrators go back and and look at things that they've archived.
That's when they look at the data.
So  this is a difficult race.
We have the same system administrators with the same expertise
who are now looking at 10 times or 20 times as much information
as they saw five years back.
So what we need are newer techniques.
And what we do with systems management
is by having a unified platform, we
can run machine learning algorithms.
The machine learning algorithms can do
things.
It can can find aggregates.
It can find clusters.
It can find trends.
It can find outliers and anomalies.
It can detect those anomalies for you.
And instead of having to look at billions of
log records you now look at the 36
things that matter.
It's still maybe 36, but it's much better than the billions
of records that you are looking at.
Vjiay, thank you for taking time to talk to me.
If you'd like more information on microservices or DevOps
or containers or any of the things we've talked about these past few minutes,
please visit developer.oracle.com.
That's developer.oracle.com.
You'll find sections for all of those topics, with a
lot of content by developers for developers.
For the Oracle Developer Community, I'm Bob Rhubart.
Thanks for watching and stay tuned.
