Build microservices and container solutions using Azure Service Fabric and Azure Container Service

Build microservices and container solutions using Azure Service Fabric and Azure Container Service


Okay, we’ll get started. A couple of people are fading in,
but, yeah, let’s get started. So welcome, everybody, welcome
to the last session of the day. I hope everyone’s had a good day. Seems to be pretty action packed, especially with a quarter of an hour
in between, everyone rushing around. So hopefully you’ve had a good first
day, looking forward to tomorrow. My name’s Mark Scurrell, I’m
a program manager on the Azure team. I’m in the product group based
in Redmond just outside Seattle. And I work on the overall
Azure computer team. And we’ve basically got the
responsibility for pretty much all of the compute stack, certainly
what we refer to as infrastructure as a service and a lot of
the platform as a service offerings. So I gave that talk a couple
of hours ago about IaaS and getting started with Azure. So our team covers defining
the hardware roadmap, rolling out the new hardware,
exposing that via VMs, exposing that via higher level
capabilities like scale sets, a container service we’ll discuss
here briefly, batch and so on. In particular, I work on what
we call the big compute team. My sort of main focus from day
to day is large scale computer work loads. And often I sort of talk to people
who leverage, really do leverage, the scale and elasticity of Azure. You may be deploying 3,
5,000 cores for a few hours and scaling back down again. So pretty interesting,
it’s been pretty fun probably over the last four years seeing
how the move to the cloud and how Azure has developed. So in this session, we’re gonna
basically cover about maybe 90, 85, 90% of this session,
we’ll cover sort of microservices, and be very much focused on
then sort of implementing some microservices with Service Fabric,
and really that introduction. Now, I’m gonna just give
a very short sort of overview, a sort fo brief demo, of setting
up ACS, Azure Container Service. But really I’m not gonna go
into any sort of detail there. Sort of really the main reason is
there’s a lot to cover even to sort of provide an overview of the
microservices and Service Fabric. And then there is, tomorrow, a really sort of deep dive
into the container service. So if you’re coming along and
you want that more detail on ACS, I don’t want you to be
disappointed with the session. We’ll cover it for
about ten minutes at the end, but the majority of this talk will be on
microservices and Service Fabric. And check out the session
tomorrow at 1:45, a colleague of mine is giving that. So let’s get started. It’s sort of interesting cuz I
was sort of involved in, before I joined the main Azure team, I was
on the SQL side, SQL Server side. Worked on, I think it was,
SQL Server 2008, 2008 R2. And was involved in the move
of SQL to the cloud. And what we used to call SQL Azure
and is now Azure SQL Database. So if we go back, I mean this
may be five, six, seven years. We sort of had this
challenge with SQL and actually a number of our other
products that we wanted to sort of take these existing
on-premises applications. Sort of developed in a certain way,
deployed in a certain way, managed in a certain way. And create, basically,
the cloud versions of these. And there were sort of
pretty interesting sort of things we had to consider and
take into account. That sort of really sort
of influenced then, well, we sort of need to build
up some platform and capabilities to sort of really
cater for the differences between on-premises-based applications and
cloud-based applications. Whether writing from scratch or
effectively, in our case, we were moving or effectively porting
a code base so it ran in the cloud. So first, there’s a bunch
that are maybe obvious here. Obviously, we don’t own
the hardware anymore. Even when I was working on SQL
Server, we used to have, initially, there were sort of big
almost like mini data center rooms within our building,
and we had a bunch of servers there. There was a sort of data center
sort of fairly nearby for some of the workloads. But now with the cloud,
I mean, literally, we’re sorta deploying this,
we’ve got our, is it, 36 regions, we heard this morning,
around the world. And we’re nowhere
near this hardware. So we can’t even sorta just
even drive down the road or the freeway to go and
see if there’s an issue. The hardware, again,
I’ll draw some analogies from SQL, the hardware is pretty different. In the SQL world, we were used
to you’re rolling out really hardened production SQL Server and
capabilities built on that. And you’ve got high end hardware,
very reliable SCSI drives, blah, blah, blah. And very expensive, but very reliable because you’ve
got that set of hardware. And then we’re sort of moving
to the data center where we’ve got clusters and clusters,
hundreds of clusters, in there. Obviously, a lot of the time,
it’s sort of commodity hardware. It’s almost like Azure in the cloud,
we build it, we expect failure, we know big pieces are gonna fail. And part of our challenge,
and actually our job, is so that you don’t get impacted by that. But we have to deal with that,
hard drives failing, motherboards failing, network
switches dying, that sort of thing. So a lot of what we do in
our platform is being able to sort of cater for
those failures, hide them, certainly recover from them and
so on. All the while, certainly with all
the servers that we have within a region, sort of ensuring we
don’t have to have hundreds and hundreds of people
managing them as well. But in terms of developing
the software, there’s very different types of software actually,
there’s a whole bunch. At the time,
we’d go into these machines here and they’ve just got IDE drives, and with SQL you need to be
running on SCSI drives. Scale, scale’s pretty interesting
and can be predictable, or unpredictable, can be predictable. But you certainly, how do you scale, how do you ramp up with increased
usage or even sort of cater for sort of decreased usage at
sort of times of the year? How do you cater for peaks, like
holiday season or Thanksgiving, and still be efficient in buying a lot
of stuff that you don’t really need? So we have to be able to
scale our services and scale the software
that we’re writing. I think managing them is
definitely a challenge, as well. I heard a lot of learnings
around managing this. Yes, it’s far away. Yes, there’s thousands and
thousands of these servers. And we’ve got tons of
people using these things. And it’s not just like your scopes,
you’ve got maybe your SQL Server deployment, and
you’ve got to manage those two or three machines or
ten machines or so on. We literally have thousands and
thousands of literally servers to monitor and manage and
ensure they’re healthy and so on. And one of the big learnings there,
and I think actually Jason referenced
it this morning, and we sort of highlighted some of the capabilities
we’re making available to you guys. For us, I think he said it was
literally in the petabytes per day of data we sort of generate from
all the telemetry that we have. And we basically need to be able to
monitor that, and not have it so it’s so noisy that we’re getting
interrupted with false alarms, but know when there’s something that
needs some corrective action. So the monitoring,
having a telemetry, having the tools built over that
telemetry has been a definite challenge in consideration for
moving to the cloud. You don’t get any downtime,
obviously. You have to upgrade on the fly, there’s no sort of
taking stuff down. Hey, look, it’s midnight,
between midnight and 5 AM, there won’t be a service. That’s just not possible anymore. Costs, managing, are you
efficiently using that hardware? Are you packing stuff appropriately,
or are your CPUs sitting there
an average of 3% utilization? Are you making the most
of what you’ve got? And, obviously,
sort of virtualization and now with microservices, with those
sort of technologies, you’re sort of really able to sort of pack things
more tightly and be more efficient. The costs, obviously, security, Jason covered that quite a bit,
and caring about that. And then, in terms of building these
applications, once you develop a productivity that you like, you’re
gonna have to, we’ll talk tomorrow, and we sort of talk about
the expectations from our customers. And I’m sure some your customers
are sort of changing in terms of the frequency of updates, and
new features appearing and new capabilities appearing. And we’re sort of rolling out,
I think over the last few years, those that have been following
Azure are using the capabilities. We’re sort of down on, actually,
the particular service I work on. I mean, literally in a week,
we can be rolling out, anywhere from one to three
updates to that service. Maybe every few weeks, there’s some big new piece of
functionality or whatever. In Office, I think a great example,
these days Office 365, with how frequently you’re notified,
hey there’s a new version, and you get a whole bunch of
new functionality there. So, how does the developer cater for
that? You need a developer platform sort
of to cater for that cloud and ensure your developers
are being productive as well. So I think this is sort of
touched on some of this, but this is where the microservices
approach effectively came from. And it’s already to satisfy
these sort of a particular like set of requirements or
characteristics of cloud. Your applications continue evolving,
continually being updated while maintaining
that up time for an example. There’s customers expecting
those fixes, very, very quickly. The new features very quickly and then obviously being
able to operate at scale. So, instead of the sort
of cycle there, doing your development planning,
doing your development testing and releasing it, monitor, is everything
okay, is it going as expected? If it isn’t, you’ve been
able to cater for that and then you’re going around again. It’s sort of, she’s just
sort of thinking about it. And again, I suppose from
the development standpoint, one of the interesting things is, I sort of
find interesting looking back on it is we used to get these at Microsoft
we used to get these ship-it, sort of rewards, but
you get a little plaque, hey I shipped this version
of SQL server 2008, 2008 R2. Maybe every one year,
two years you’d get this and let’s just say in the cloud world,
we don’t get these anymore because we’re literally releasing every
week or even every few days. And even the concept of any sort
of big release in a lot of ways is even gone away cuz it’s a lot
more incremental and fast. So it’s funny to
think how things have been changing in the last few years. So in terms of methodologies,
certainly, let me sort of go back when I was sort of developing in
early days of Microsoft as well, you sort of have your more traditional
three tier approach very frequently. Sort of client server, some sort of
back end store, persistent store, database. Some sort of middle tier,
and then your front ends. And you deploy your appropriate pieces of the application
across those tiers. So that sort of contrasts
to the microservices world, where you really just
get a set of machines, we call it a cluster
in service fabric. You’re basically just getting
a cluster of machines. You’re gonna link them up obviously,
so that they can communicate, and then depending on the services
that you’re deploying, you can just deploy your services
and effectively, the services, depending on the requirements and
the scale and how tightly you can pack and so on. You can spread them out
across that cluster. So when we build these, in the sort
of more traditional application, it’s sort of interesting in terms of
the, again, you sort of build them, and that contract, where do all
the pieces sort of tie together? Where’s that contract defined in
terms of this layer talking to this layer, talking to this layer? And it sort of can be thought of,
it’s definitely some of these layers,
more of a compiled time contract. You sort of compiling this up,
you sort of building everything and then deploying the exes or
the DLLs or the various components. So it’s all sort of local
operations, easier to think about but when it comes to sort of being
more dynamic in terms of the scale and certainly when it comes to
sort of the cloud scale, it can be really expensive to scale and
hard to scale that appropriately. And this was sort of already a
challenge that we had to go through a few of the products but obviously,
it’s the way we build the products and then we had sort of have
to change moving forward and moving some of those
products to the cloud. So really that’s sort of that
previous diagram sort of becomes this. Where you have the nodes and then
sort of various of these sort of microservices or
these components that are deployed. And so really the contract,
it’s more like they’re talking over the network or
talking sort of via our PC and so more of a run time contract as
opposed to a compile time contract. And then hopefully we can
scale that more cheaply. We can add in nodes or if a node
can be more tightly packed, we can add more instances. For example, for the front ends, without sort of changing the rest
of the things or recompiling. And even when parts of
the components change, we can update them or
upgrade them independently. So this one, we sort of start
moving to this architecture and sort of design pattern. It sort of starts to get
cheaper to scale and easier to scale the access,
and then the upgrades as well. I’ve got some a demonstration later
on when we go through upgrades and sort of upgrades can
be more continuously. So state is something that we
definitely want to highlight when it comes to service fabric. And more of the, again, approach
with databases, and obviously SQL Server, or, more recently,
the NoSQL stores, DocumentDB, or any of the other NoSQL stores,
you’re gonna have your application, and then, maybe, it’s one,
I mean, it could be multiple but you pretty much have these databases
where you’re gonna store your state. And then, I certainly know
from experience depending on the application you’re gonna
end up with hotspots there. You’re gonna end up with
some tables are access more frequently than others. And you have to work hard
how to sort of scale that. All this certain you have to
partition your data so that, hey look there’s more frequent data
that’s accessed very frequently, very often updated, read very often. And then there’s some older data,
maybe the stuff from last month or last year. It still needs to be there but
isn’t access to software so you really get some
interesting challenges in scaling out the storage and
your persistent slide there. And one of the things that
with microservices is supported by service fabric. It’s sort of that ability. It’s effectively a built-in
storage technology as well. So you can have these
stateful services and effectively the fabric itself,
the microservices themselves with the framework that we provide often
use some storage capabilities. The data can be stored
effectively without a monolithic. One big sort of store and easily
allows you, it can spread out or effectively partition that
data across multiple nodes. Use the local storage on the nodes. You can scale it out when demand
increases or scale it back down. And then it’s also resilient to
failures and node failures obviously very important if you’re storing
the data there on the node and then something happens to the node,
you can’t lose your data. So, it’s only with a service fabric
and we’ll see a demo of this, we have something called
a stateful service where you can actually use service fabric,
and it offers some storage, basically first class storage
capabilities for your application. One thing to highlight there,
it isn’t an all or nothing, again we’ll sort of
hopefully reinforce this, but you can certainly start off,
you can use service fabric, you can use microservices if that’s what
really with your existing database. I think this was what Linked did,
Linked at the time, now Skype did when
they move to the cloud was they basically took some of the
data, certainly the very high-scale, very hot, frequently updated,
frequently read data. That sort of part of the data. And moved that and started
using the stateful services and that technology and had a hybrid. And then, maybe over time,
some more moved to service fabric. And then it was perfectly fine, for some of it could remain
in that database. So it’s definitely not an all or
nothing. And in general, the move to service
fabric, what we’ll see is you can start off just by bringing your exe
or bring your ASP.NET app and so on. And then, and
you get some benefits there. And then as you invest more in
the maybe the frameworks in developing these specific services,
stateful, stateless services, you’ll get
more and more of the benefits. So it’s definitely not an all or
nothing and they have to jump in and
a big thing. You can get there gradually. So just to reinforce some of the
benefits there of sort of splitting the application up into these
sort of separate components. Covered some of these very briefly,
but sort of scale definitely
is one of them. If we’ve got a sharing service and
a thumbnail service but you need to generate
a lot more thumbnails. Whatever reason
the algorithm you take, you’re switching from
a simple algorithm. Maybe it’s more of a learning, and
do a clever sort of thumbnail. Then you might need to
sort of scale that out. And be able to do that independently
without impacting upgrading, or taking down the rest of the, some
of the other parts of the service. Different technology stacks,
definitely possible. But obviously,
they’re independent pieces of code, you can develop them with
different pieces of technology. Could be legacy components that you
need to use with sort of .NET, and maybe in the new stuff
you’re using node.js, for example Version them independently, we’ll see this actually coming up
in a few minutes, version them. Have the other one there,
you don’t need to upgrade that. But just independently update
to V2 for the Thumbnail Service. And then it’s a little bit
of a maybe an Edge case, maybe sort of an interesting one, is basically each when you
got the share dependencies. And you could update the dependency
needs to be a newer version is required by one of these
microservices, and not the other. So, we can have
the thumbnail service, and then used this shared library. So, some of the benefits. But we’ll see is, or if you sort
of take into account, now, well, I’ve got this cluster,
it could be any number of nodes. I could have effectively
multiple applications I’m gonna deploy to these,
each with different services. Or can pull microservices. Some of them stateful, stateless. Notes can come and go. I need to upgrade. It’s, yeah, this is all great. But I need to cater for. Now, sort of provide the sort
of capabilities around the service discovery. I need the built in
state management. I sorta need to be able to track,
well, what state are my apps and even these services? In terms of, are they healthy,
are they unhealthy? Are they being upgraded? Have they finished their upgrade? If, in fact, you’ve got this
cluster with many apps in it, and many parts of those apps, there’s quite a lot you are going to
need to keep track of and manage. Manage the health, and
know what resources are being used. How well they’re being used,
and so on. So, sort of these become
the requirements, it’s almost like the fall out. Well, this is great, but then
that means we need some of these capabilities, or need to cater
sort of for these cases. So, that’s really where
the platform comes in. You sort of really need
a microservices platform. Both design, there we go. So, you sort of design and
build your microservices. Have a platform for that. Then as well as, actually,
yeah, and sort of cater for the build the applications,
build many applications, and provide the flexibility around
language and frameworks, and so on. And then once you’ve built them,
be able to roll them out, maintain them, upgrade them,
know that they’re healthy. Monitor and manage them. So, they sort of really become
sort of the main requirements. And this is really where
Service Fabric, or really what Service Fabric
was built for. Oops, let me go back there. So, really sort of cater for, we’ll
go into a bit more detail soon, and cater for
building those microservices. And then providing that platform,
so you can actually deploy them, everything from the lifecycle
management to the autoscaling and the tooling and so on. And then I think the key thing with
service fabric is the ability, both Linux and Windows there, that
really talks to the flexibility and choice around even effectively OS, as well as sort of frameworks and
apps you want to run. But then where you deploy it, I think sort of particular strength
is, and I’ll be doing some demos. I’ll just be doing my dev box. Effectively, we’ve got
a local dev cluster there. You can deploy to Azure,
have a whole bunch of nodes. Now, you have some massive scale
in Azure using either Azure VMs, or containers on Azure VMs. But also, be able to deploy
it On-premises as well, or you’re effectively private cloud,
Or even other clouds. I think there actually is an example
of a service fabric being used, and then it was, the application
ended up getting deployed on AWS. So, it’s sort of really
providing this platform. So, I put this in and
sort of went through and sort of [INAUDIBLE] some of
the internal services, or internal products that effectively
use, or powered by Service Fabric, I talked about SQL database, and that
was probably one of the first ones to really led to the evolution and
production of our Service Fabric. But you can see here a whole bunch
of other services, a lot of them even more recent ones around
IoT hub, event hubs, and so on. And all of these,
they’re all huge scale applications, obviously all have a lot
of states and so on. All running effectively on Azure,
and all built with Service Fabric. So, go into a demo, really, what I want to do is after that
introduction, we sort to talk a little bit about the microservices
and the difference. And then I’m gonna jump
into this sort of demos, and go through some almost
a hollow world demos. This is pretty deep area,
in terms of Service Fabric. So really,
sort of just my goals here, is sort a just to
give you that flavor. Sort a give you the flavor on the
background there, and then why, and then sort a give you
a flavor of Service Fabric. But I’m sort a gonna keep it,
we’ll sort a keep it fairly simple just to get, so you’re familiar
with some of the concepts. And then if this is of interest to
you, you can go away and dig deeper. And there’s some links and
stuff at the end. But they’ll probably have
even a full day or so on Service Fabric sessions to
really do a deep dive for you. All right, so
we’re gonna do a stateless service. All right, let’s hope. I’ll use, I’ll do my best here to,
I know it’s small. I’ll set the font up, and I’ll do
my best to use zoom it as well, so to cater to
the folks in the back. So actually,
what I’m gonna show you, effectively is the Hello World
of stateless services. And it’s really actually
a really nice example, literally, just built in and very illustrative,
into the initial templates. So, on VS here, and you see in
the templates, I’m gonna use C#. And then, cloud. And then, in here, obviously,
we’ve got some of the other Azure capabilities, web jobs,
mobile apps, and so on. And then here,
we’ve got this Service Fabric. So, I’m gonna pick that. Now we’re gonna touch on
all these a little bit, but probably really mainly these
two, stateless and stateful. So stateless is maybe where you’re
developing something that literally doesn’t have any state, completely
stateless, or the component itself is stateless, but it’s working
with an external database, or no SQL store, or
something like that. So, we’ll touch on that, and next,
we’ll move on to the stateful. So, this is literally going to build up a stateless sorta microservice, and it’s pretty simple, that is pretty
illustrative in terms of all it’s gonna
basically do is count. And so we have an iterations here,
starts off at zero, and then we’re gonna count using
plus plus iterations here. And it’s basically gonna count, and it’s just gonna go around in
an infinite loop and count. So just to, hopefully,
we can sort of see here. So, this is sort of starting
to use the, obviously, we’re in Visual Studio. We’re sort of in
the development phase. And so, this is sort of the,
almost the introduction to some of the frameworks that we’re providing,
and the programming models we’re sort of providing to produce
these microservices. So there’s a, what have we got,
sort of listeners? And then this sort of run async. And just again, for
this super simple example, we’ve got just literally
everything in here. Iterations is to zero, and
just forever go through and increment that. So, before I run that, what am I
actually gonna run it, deploy it to? And I sorta talked about the
flexibility from being able to go from anything, from a local,
even on my laptop here. A local cluster all the way up
to maybe thousands of nodes in, thousands of VMs in Azure. And then maybe somewhere in between
is your On-premises cluster. So, I’m just gonna use
the local cluster here. So we’ve got the tray here,
and we can display that. So in hindsight, it’s pretty nice,
easy to use effectively Explorer, or local cluster manager
that we provide here. I think it’s worth to just sort of, we’ll dig into sort of the main sort
of sections of this in a second. So I’ve got my solution here. It’s already to go. All I have to do is hit start and the default configuration is
to use this local cluster. And so hopefully in the output
there, we can see it deploying, and this will sort of
freeze it in time a little. But in this diagnostic events, so
part of the code emitted diagnostic events, and you can sort of
basically see it counting. So there we go,
up to 15 all ready, 1 per second. So that’s running. So let’s have a look, what does
that look like in Service Fabric? So it’s sort of your typical
explorer, tree view on the left, details on the right. So we have our cluster here,
and provides the overview. So it sort of simulates five nodes. Everything’s healthy, and we’ve got a dashboard here
that shows the applications. And basically, we’ve got this
one application running, and it’s healthy. And we’ll have a look at
upgrades in a few minutes time. No upgrades running. Some more drill down here,
I just wanted to introduce this. We’ll see this later, and it’s sort of this concept of fault
domains and upgrade domains. And I touched on this a couple of
hours ago at my sort of IaaS or infrastructures as
a service session. And so this is a way where you
have these multiple domains, faults, or upgrade. And it’s a sort of a way so that
you can have effectively multiple, like in some cases in Azure and in
an availability set, multiple VMs. And they’re in different
fault domains. So if sorta like the worst
of all faults happens, then it only impacts the things
in one fault domain. So part of sorta the deployment and part of sorta the management
capabilities for Service Fabric. And then it’s also analogous in
Azure is effectively the placements of the microservices, or
the placements of the VMs. Cuz you want to place them so
that if there is a particular fault, it’s sort of isolated and
has limited impact. And the same also goes for
upgrades as well. We’ll see the upgrades
in particular. If you’re performing an upgrade,
it’s not a big bang and you’re updating
everything at once and even your service pauses for
even a few minutes. You’re gonna upgrade. And actually, even what we do,
a strategy for the upgrade, is you might do a partial upgrade. And then you spot a problem. So, certainly, what we do in a lot of our services
is we’ll go through and we upgrade. You upgrade in stages. And so it’s just little slices. So your system is continuously,
obviously available. But then if you notice something
wrong after the first, you can either roll back or correct
it without rolling out any further. So there’s sort of both a fault
case and an upgrade case, when it sort of comes to the robustness and
reliability and availability. All right, an seriously,
enough talking about that. So that’s that. So we’ve got applications. So we can see application three. This was application three. I’m just gonna dig into this. There is a piece of
information we won’t go into. But at the end of this, we get
a node, so we’re on node 2 here. If we go to the nodes, and
say this simulates five nodes, we saw those split across
the fault grade domains. And there’s no drill down here. But if I look at 2,
as this indicates here, we can actually see my application. I can see it says stateless 2
package, and there’s some code. I know, it says too much, no. And a particular instance of that,
but basically the bottom line, I exposed 3 and 4, I’ve just developed
this one stateless service. And it’s deployed to one node. So what happens if that node,
node 2, something happens with it? There’s a blip, goes away, for
whatever reason, it might be a few seconds, it might be a few minutes,
it might be a few days even. So what we can do is
simulate that here, and we’ll do a restart on that. So we get the confirmation. And let’s restart. So this is quite nice as well. You can refresh it up
to every two seconds. Works well. So there’s sort of two things
to keep an eye on here. We’ll keep an eye on
this left-hand side. And we’ll keep an eye on this here,
on the left-hand side here. So, I’m gonna click on there and
then zoom in. So, we can see here, it’s working,
it got to about 256. Then basically some stuff happened
when I restarted that node, the node went away just for
a few seconds. So, obviously, this is pretty
low-level diagnostic information, but hopefully you
can sort of pick up. And it’s basically Service Fabrics,
basically saying, well, look the node’s gone away here and
I was running this service on here. I need to find somewhere
else to run it. So, it goes and finds, look I’ve got
four other nodes to run this on, and goes and picks a node and
will run it. But the particular thing about
this case is that obviously it’s stateless. So, hence my count. My count was just
sitting there in memory. Hence, my count is been reset. So, obviously, as I said earlier,
I sort of just wanted distress we can have a stateless service here
that’s working with the database or even Azure Storage,
Azure Tables, NoSQL, DocumentDB. Okay, so whatever it is,
providing that persistence and the robustness for you. But, in this case,
within the stateless service, obviously it’s not
providing that for us. So if you remember,
actually it was node 2. So, let’s have a look here. We can see the other thing to
notice is that this service now is running on node 4. So we can see in explorer here,
and if we looked at it, I can do it again. If we go node 4, restart that. We’ll sort of see it, instead
of focusing on the left-side, on the right-hand side,
we should see the nodes restarting. There might be some
error information. And then it just depends on
the two seconds time, but we should see this then reset. There we go, it sort of found
out and it’s going to node. It’s in the process of
moving to node 2, and then within a few seconds it’s
up and running on node 2. So this is another example of how
you can, we’ll talk about a little more, but if you’ve got an
investment in Azure at the moment, say on cloud services, or you just got an existing
XC that you want to run. Here’s an example of,
you can give it a set of nodes and how Service Fabric can
start to manage this for you and provide some
robustness that you need. And effectively sort of the healing,
and the monitoring as well, to detect something went wrong,
and then heal from it. So that switched over. All right,
it’s actually the other thing. Sometimes some other
error messages pop up, but it’s because there’s a number
effectively of internal services that we’re running on this as well. So, again,
they have to all be robust. And if any of the nodes go away, they have to maintain what the state
that they have and then recover. So once I’ve just stopped that,
and we can see this then starts to clear up and
this will come back, there we go. That’s basically empty now. All right, so that was stateless. So, really, it applies to
both Azure or on-premises. And so the key thing here is, we
could have, probably at least three nodes, but you could have
thousands of nodes here. So, sort of,
what’s the workflow here? So you could have some
on-premises machines, you could have some VMs
on-premises or in Azure. Effectively, the group of these,
they form your cluster and Service Fabric installs on them. And effectively,
they form this ring. Actually, it’s a ringed topology. You’re gonna have
your load balancer. Actually even what Visual Studio’s
doing here in deploying this, it’s going in to the cluster,
through the load balancer. But in our case,
when you’re deploying apps and management operations,
it’s talking to the Service Fabric microservices that are sitting there
and performing those operations. And then we’ll, see towards the end
a demo, with a web component. If you’ve gotten the [INAUDIBLE]
of your customers, you’ve deployed the app. Maybe you got some web frontend,
again, that comes in through
the load balancer and finds the appropriate instance
to point that load to. So Service Fabric obviously
knows where the codes live, handles failures, restarts,
processes, provides that robustness. And there really isn’t,
I mean, I suppose there’s none of these nodes that
are effectively are the master. Effectively the master node for each particular microservice
can even change. I think as we saw,
when we restarted things. In one case, the master node for
a particular service is four, and then if something happens
then it could be three. So we talked this stateless
services, and statefull. And that sort of all wrapped up
into these reliable services, and that’s one part of the framework. And in VS I think we saw that,
we’ll see it again in a second. There’s another framework for
actors. And these actors sort of uses
a virtual actor pattern. It’s sort of very good for
having lots and lots of objects sort of
single-threaded objects. And they can have their
own state and so on. And you sort of see the use of
those in a demo in a second. And it’s sort of based off this, or implements this
virtual actor pattern. So it’s basically another choice
that you have for some workloads. You can bring your own apps or
develop ASP.NET apps. And I think I Ethan mentioned
as well, you can even bring a guest executable and
you get some of the benefits. Things like the monitoring,
and restart, and so on. Maybe some of the scale
out with service fabric. But it’s one of those things. The good thing is you can
sorta stage your investments. And then maybe later on start moving
to use the reliable services or the reliable actors. And really adopt some of
the framework as well. Yeah, so I think we sort of
really went through that and the frameworks. I’ll talk about the,
on the reliable services and the data structures it’s best we’ll
just even, I’ll show you that. Which should be now. So let’s have a look
at stateful service. So there’ll be a lot in common here,
but it’s cool to sort of see
the difference here. So let’s do a new project,
do exactly the same. So there was the active service I
mentioned, the guest executable, and so on and
here we’ve got our statefulservice. So this will look
pretty familiar but there is a pretty obvious
sort of key difference. So in the code it generates,
yeah, not the same, imports, this is all pretty similar in
terms of the listeners and so on. And here’s where the difference is. So we’re in the main run async here. And it’s really,
this is sort of where I talk about, I feel like the first class
sort of storage technology. So you can see that
we’ve got the concept. We’re gonna increment the counter. We’re gonna do a plus plus value,
it’s called, in this case. But we’re going this in
the context of a transaction on the state manager. So the state manager you can
use to manage your state. And this is all exposed
via sort of a dictionary. So you don’t get, for example,
so for this technology now if you need some big almost
equivalent of cross-table joins. Or a whole bunch of indexing, or
there’s definitely cases where you absolutely still need
the appropriate, say, SQL store or
no SQL store or whatever. But certainly for
maybe some parts of your data. The sort of particularly
frequently used data. Sort of the,
what’s in use at the moment? Maybe where you’d want to cache,
as well. The stateful capabilities
really can come in useful. And then the stuff that
isn’t as frequently updated. And there isn’t the load, then you could continue
to use your other store. And this is a strategy,
again I believe, that I think Lync used as well. Moved some of the data and
did it in stages and moved some of the very hot data into
the storage here for service fabric. But basically it’s pretty
straightforward within the context of a transaction. We are getting the counter and then
we are updating it, adding one, and then we’re committing it. Other than that this is the same. If we go over here this
is basically empty now. So let’s We’ll deploy that. So we’re registering it. We hop over here,
we should see this start to deploy. And there’s a key difference here
we should notice pretty quickly. Okay, pretty much done. There we go. All right, so we’ve got our
application, application four. This is what we’re, definitely
what we’re just running here. If we dig into this and
we dig in the particular instance, now instead of one node
we have three nodes. And there’s a primary and
two secondaries. And so this is some of the core SQL source capabilities that
Service Fabric provides. And it sort of follows, again,
the same pattern here in the early days when we were working on
SQL Azure or Azure SQL Database. It’s how do you have these sort
of commodity hardware with, they’ve got their own disks and
everything. And you need multiple
copies of the database. How do you provide that
availability and robustness? And so
we have the ring topology here and we’ve got basically three nodes. And we have a primary one for
the data. But when that data is committed
It’s always written to at least two places before
that transaction returns. And then it could be written to
the third one asynchronously. But your data is always, obviously,
in more then one place at a time. But then there’s always backups here
that are backups that are available in case of an issue
with the primary. So that’s why we’ve got three here. Because we’ve got states. So we can see that across
the nodes as well. We’ve got the application over here,
here, and yep, here, which is what this says. So that’s the same pattern,
as I said, with the system. Some of these effectively
system services, you could see them running
on multiple nodes as well. So if I push that off to the side, let’s have a look and we can see our
counter’s still working away there. So that’s exactly
the same as last time. So I think one of the sort of key
things is what happens here if one of these nodes dies. So Node 2 is actually the primary. Actually, we’ll restart it. So we should see pretty
similar to last time, see the, that said it was restarting it. We should see some change on
here when this refreshes. There we go. And it says the node’s down and
it’s come back again. It actually has come back again but
now it’s the secondary and not the primary. Let me go across I can actually
use the zoom it to freeze that. So we can see what happens here. This looks pretty different
because it’s noticed it’s stopped. And it’s registered a new
service to keep it going, to keep sort of those
three copies going. But my counter still hasn’t reset. So this just seemed like a very
easy to see sort of differences between the two services. Just because it’s persisting
that counter value even though the node has disappeared and
it’s failed over. So obviously it was robustly stored
and then it sort of failed over and the other notes picked up. So it’s a key difference
between stateless and stateful. All right, so that’ll clean up. So one of the capabilities we
had in Azure basically from pretty much from day
one was make a cloud service really a platform
as a service offering. So this we had VMs but we provided
some higher level capabilities on top of those VMs and
called them Cloud services. And when we have some
capabilities to allow you to increment the number of instances. There’s some API around it, has an
instance gone away, and so on there. But it really sort of supported
the multi-tier design. You could have had
the web applications, or basically you’ve got
multiple roles within that. And even the cloud service model
that you use to define your cloud services has more and
more roles that you define. So which basically equates to
these layers of your application. And these applications obviously
work with the various, they work with subsistence
storage or cues or the various caching or
SQL and so on. So with Service Fabric,
that changes, we’ve sort of seen this before. But really just to emphasize,
you can take that and then you can break it up
into the microservices. And then use Service Fabric
to manage that for you and break up your roles. So the layers or the tiers of
your application, have them as the microservices and have
Service Fabric manage them for you. And obviously, initially one
way to break that up is, you would leverage the state list. You’d still use the database,
you’d still use the Redis cache, or whatever that. So for small services, sometimes one
of these previously and was asked, well, look, I’ve I’ve used cloud
services, I’ve got an investment, it’s relatively small, I can
manage it fine, it scales fine for what I need. Should I just proactively move? And the answer would be no. I mean, if it’s fine for you and
it’s not an overhead for you, they’ll work great and
it’s gonna continue to work great. But maybe you were
contemplating something new or you’ve got a big upgrade coming up, then definitely worth looking
at the service fabric approach. So we’re gonna look at
the rolling upgrades. So this is where you basically have
two tiers or your sort of two rows. And we sort of split it
into these microservices. And you want to independently
update one of these. So what’s these microservices? It’s managed, it might only
be on some of the nodes, it might be on nodes with some
of the other microservices. So how does a rolling upgrade work? And it sort of uses the concept I mentioned earlier
about these upgrade domains. So this is where the service
instances that are running are split up into these domains. And then as you upgrade,
it only does one domain at a time. Which basically maintains
your availability for you. And while it does the upgrade as
well, it’s looking at the health, maybe assuring it’s healthy, nothing’s gone wrong
before sort of continuing. One of the questions comes up
sometimes is, well, does the service fabric or the framework sort of help
you with that contract validation or, yeah, validation,
that I sort of talked about earlier? The contract between
the various microservices? And that’s still something
that you have to work with. You don’t want to upgrade one
of these, make a change to, was it, the service package B
in rather small font there. Make a change to that, and
you break the contracts. You maybe effectively
are breaking change. It is up to you to maintain
that compatibility. All right, so let’s try and
do a, we’ll do an upgrade. So I’ve got a visual example for
this. Okay, it looks like, so
our cluster is cleaned up. We haven’t got any applications
on here, that’s good. Minimize that. So I’m using a solution that was
developed called Visual Objects. And you’ll see why in a minute. So this is one of
the sample we publish. And they’re sort of
specifically designed to, I suppose it shows two things. If you’re interested in the actor
pattern, it actually uses actors. And we can sort of see here
it uses the actor service and implements the AI
visual object actor. So that’s one thing but it makes a
particularly good demo for upgrades. Because what you’ll see is, we have
lots of objects and they all have their sort of state and they know
where they are on the screen. We’ll see that, and
there’s a number of those and we want to sort of upgrade to
this particular actor code here. And not the front end, and
update that independently and see how the upgrade works. So it’s specifically designed for
that. So you can find this online if you
want to run it when you get back. So the key thing here is, so
we’ve got an application and we’ve got a move object. And I won’t go too much into that
yet, we’ll come back to that. I’m gonna deploy this,
because I want to do an upgrade. I’m going to just play it slightly
differently, I’m gonna publish. So this is almost like what was
automated in the previous demos. I’m gonna publish this. It’s gonna go to the local cluster. I’m not gonna upgrade, and
I’m just gonna show you. So for
the various packages that we have. Actually, let me split that out. There’s a, oops,
there’s a versioning. So we can see we’re starting
from our initial version here. And the sort of component and
the configuration, everything’s, basically version 1.0.0. So effectively, we’re gonna
publish this for the first time. So while that’s publishing,
so this is sort of, there’s two parts to this. Let me go in on
the right hand side here. We’ve got this actor service, and we’ll see what the individual
actors are doing here. But then there’s a web service,
there’s a front end to this, this exposed web service,
web UI, so we’ll see that. So there, and
then there’s a common solution here. But we’re gonna upgrade
the actor service independently. So that’s deployed. Looks like that’s on,
it’s deploying. The state associated here in these
actors, the state associated with them, so they are partitioned
across the five nodes that I have. And I think so, actually, so
then in this five upgraded domains. So, basically one node effectively
will get upgraded at a time. All right, so
I think that’s deployed. So we can see we want to,
here on the applications, we’ve got sort of two services,
the actor and the web. So let’s have a look at that web. And it’s exposed by this, so
suppose a local host for this port. And there we go. So basically we’ve just got
bouncing triangles leaving a trail, and that’s all. Basically, each one of
these is the actor. And if we go into here, in the move
object, we are moving the object. But when we’re moving it, and
this sort of particular thing here. We are moving it, but then there’s sort of like a false or
is a boolean associated with this. And this is sort of a rotation. So you’re saying hey, move this thing but
don’t rotate it while it’s moving. And now you can see here what we’re
gonna do is we’re gonna change this. So, you can even see in
the background here these things, they’re not rotating. They’re just moving along. So let’s upgrade this, and we’ve decided we really actually do
want rotating as well as moving. And we can simply do that. Build. And then we’re gonna publish,
so that just built the, we built the actor. Now what we’re gonna do here is,
The exactly the same, Dialog here, and we go into,
say, upgrade this time. And we’re gonna update the version. So the way that we can do this
is to say, look, the only thing that we’re changing here is
the code for this actor package. And we’ll change that to two. So overall it changes to two, but the web services remains
unchanged and save that. And we’re gonna end and
take the upgrade. So we’re going to upgrade the
application and then publish that. So we should see a difference both
here in the output window, and we’ll see a difference in
the cluster manager in a second. So let me go back here. We’ll leave those guys running away. Let me go back up to the cluster. Hopefully we can see here
that it’s doing an upgrade. And then here,
we got an upgrade in progress. So if I select that,
let me zoom in here. So we can see that we’re upgrading,
and it’s doing a rolling upgrade. And it’s gonna do a rolling
upgrade by upgrade domain. And we’ve got effectively five
of them here, zero to four. And our upgrade is in progress. So while that is in progress, it looks like it’s done zero,
let’s sort of shift back here. So if you can [LAUGH] actually see,
as it’s going, obviously this guy was in
the first upgrade domain. And as we go,
we’ll see the web’s still available. Everything’s sort of still running,
and then just for the time, the particular part node. So these are spread
across the partitions. The partitions are on
each of the nodes. So there’s a slight pause
as that node upgrades. But sort of the key thing is the web
service is constantly available. All the other partitions or the upgrade domains
are currently available. And then in the end,
it looks like that’s finished, it looks like everything’s rotating. It is,
it says it hasn’t quite finished. Might be some there. Maybe this is a two second thing,
there we go. We just maybe caught the wrong
end of the two seconds there. So we can see the upgrade
is finished now. And I think the actor is a two, which I changed to two,
but the web is at one. So sort of the key thing,
and you can go back and forth all the time or
stop the moving and so on. But hopefully this sort of
Illustrated just a couple of the sort of the key concepts in
terms of where we sort of did have state here, that was maintained. We had sort of these actors which
we’ve effectively scaled out amongst many nodes and spread out
across these upgrade domains. So that then when we do the upgrade, we sort of maintained overall
availability of this application. And then just done each
upgrade to main as we go. One at a time until
they are finished. So hopefully that’s sort of, sort of fairly representative and
gives you an idea, anyway. On the upgrade process. All right. I’ll shut him down. So when it comes to
the Service Fabric, it’s where I want to just finish off
here with a few references. I’ve got to find out tonight,
I’m going to try and find out,
even [INAUDIBLE] ask the experts. Session but I’m hoping you guys
get these decks to download. Because there are some really good
useful links here in terms of some videos, and obviously we’ve
a number of the external customers. I think Jason actually this morning
talked about talk talk so to speak. Mentioned maybe some
of those other guys. And there’s some great case
studies as well in the blog and some resources,
where do you go from here. So hopefully, you guys can
get the decks with the links. So, that’s all I had
on Service Fabric. And then just in
the last few minutes, I just wanna sort of touch
a little on containers. And I don’t know if anyone’s sort
of really looking at containers. Sort of pretty hot at the moment in
terms of ways to virtualize your applications. And actually I was watching
the other week a video with on, and he talked about the relationship
of virtual machines and containers which I
thought was pretty good. Really, I think virtual machines, it’s all about virtualizing
the hardware and the servers, we provide those
layers with the, obviously on the bad metal there’s some sort of
host duress and then a hypervisor. Something to manage
the virtualization but then you’ve got these guess OS’ and
this is already meant to show the proportions
that an OS can be pretty big. And on top of that, binaries and
libraries and then your application. Maybe there’s even multiple
copies of your application. But obviously huge,
huge value with virtualization over running on bare metal and lots
of flexibility sort of provides you. But then with containers, and I
sort of picked Docker, docker here. You’re sort of really almost like
virtualizing the OS, really. And in fact sort of the container
really is more of a zip. And you can, it sort of
really hierarchical as well. So affectively,
you sort of virtualize the OS and you have got multiple
copies of that. And then you can sort of build
delta’s arc in terms of changes to the OS, for that and then an incremental container
image maybe for your. Maybe the binaries and
libraries, and then even an incremental container image for
the particular applications. So, it’s already sort of
about virtualizing the OS and because you’ve sort of got. You know haven’t got multiple
copies of the OS you can, should be able to more than
tightly pack your applications. You’ve also obviously got the,
the capabilities in terms of the, you have a lot more flexibility and responsiveness around starting
up and shutting down. And this is already place
in general to the moving to the cloud and
being elastic and so on. And so you’ve got to really enable
that ability sort of to quickly deploy the applications, containerize the applications,
tear them down. Deploy them, scale them and so
on and really sort of be elastic. So in Azure, I think, I mean it appeared maybe in
preview early last year or middle of last year and then we’ve
toward last quarter of last year. So we now have
the Azure Container Service. So really our goals with
the Container Service was to really support the various, well, we support the various sort
of container managers and sort of containers in general in
the open source frameworks and capabilities that were available,
but really, sorta, take away the complexity around,
sort of, configuration, deployments,
how you, sorta, set these up, how you set them up in different
numbers of VMs, and so on. I think, really, when you need to,
sorta, deploy these, you can end up with lots and lots of configuration
that needs to be determined and you know, can be quite an effect
to sort of set these set up. You know,
a cluster with our containers. So, as we’ll see what’s involved in creating
a cluster with a container service. So that the real goal is hopefully
with just a few clicks and really simplified configuration,
you can deploy containers. And I think the other thing is,
you know, we want to support
exactly what’s out there. We want to support. The container manages in terms of or
or DCOS or whatever. We’re all about making what
the community has produced or various people have produced and
what is out there and popular and what you might be using. And give you that choice. And allow you to use that but
make it super easy to deploy and easy to manage within Azure. So yeah, I think the last
point in there is interesting, we’ve obviously got the, this
enterprise grade infrastructure, all the things we talked
about in terms of trust, in terms of the compliance and
the scale and so on. We’ve got this enterprise grade
infrastructure and then you can make it easy to deploy these OSS,
open source capabilities on it. So what’s involved in creating,
basically, a cluster? This is time for
the portal, Azure portal. I just All right, so start.azure.com,
we’ll go to the portal. So, those that saw an earlier
session I did on IS I’ve got my tech summit dashboard here. I’ve got the list of services I
frequently use on the left here, and near the top Container services. So, we’ll have a look
at this guy later. I’ve pre-created one just so we don’t have to wait the five to
ten minutes for it to get set up. So, let’s create a new one. And then we’ll have a look at that,
the one that’s already been created. Yeah, got to do that. So we need a username,
we do need a public key. Paste that there. This is my Azure subscription. Talks again early on about how
an account, your Azure account and then multiple subscriptions. I’ve got a few I’m gonna
deploy to this one. I’ve got a resource group. So let’s just say ACS demo one, so just as reminder of those that
in new, a resource group has a set of Azure resources and when
you’ll see, when we creating this, we creating a number of VMs
we’re setting up the networking. We’re setting up network rules
associated with the VMs, the storage accounts and
so on there. So a resource group allows you
to group a set of resources for an application normally. You group it into one and then you can sort of makes it easier
to manage as an overall group. Updated, deleted, whatever. I think you can even get
some billing information on what’s been consumed by all
resources in that resource group. And then my location. So that’s the basics. This is where we get the choice. So, three main, we’ve got sort of
the three well known choices here, this one could DC OS. And just, I’m gonna pic DC OS, that’s just what I’ve
got this set up for. So here I can pick my counts,
in terms of agents, so the number of nodes in the cluster, so that the three, maybe,
I can pick my VM size. This is just a 2 core machine. Now we can again, I showed this. Pick my sizes,
get some recommended size. Let’s go with this guy. Again, a two core machine,
it’s actually slightly faster. Concept to master counts. I can get help here
with the little hovers. And then prefix. So that’s a prefix. We’ll see that in a second. I could enable diagnostics. So click OK there, runs
the validation just as it does with the templates or
VMs or anything else. And then that started
the deployment process. So again, it’s the little
notification window up here, lots of notifications. And we can see, okay,
this deployment has started and in progress. So this takes about
maybe ten minutes or so. What does that look like
when it’s finished? So I have, and you saw earlier,
in the container service, so we can see, here we go, yeah. That was sort of
the pre-created one. This is the one I just did,
so that’s deploying now. Let’s click on the pre-created one. So pretty much very consistent
with other capabilities in Azure. Get the overview here or
what we call the essentials. This is a key piece
of information here. But information about sort of
the agents and the agent pool. This is the particular size,
how many counts. I can update this. So various capabilities here,
but it’s all really about, say this is all about managing the
infrastructure required on which to deploy, this container service and
the container manager. So let me go back to the overview,
so we can see we basically got the, Basically the name of this. Effectively this exposed the end
points to this cluster, and that’s exposed here, so
we need to connect to that. So the way we do that, I saw it in
the getting started documentation. So we’re not say, there’s nothing. This is all the existing,
the open source stuff there. The manage it there. And it’s exposing its
sort of capabilities. DCOS, via HTTPS. So the way I can actually
tunnel through and get it back on the master node is
on Windows here is used Putty. So basically what we’re gonna
do here is set up an SSH tunnel. When I set that up,
I had to put in a public SSH key. And obviously that’s required for
the containers. So what we want to do to be
able to see this here and effectively tunnel through
to like the master VM. And the service running on
there is I would need to set up a SSH tunnel and
I can use Putty to do that. So let me load in
the configuration and I know this is I’ll zoom in here. So this is exposed, so this host
name the hostname that you can see here is equates to yeah there
we go on the left hand side. So this is sort tunneling
through setting up an SSH tunnel through to that master node,
so yeah, I’ve loaded that. I can open that. I need to type in the pass phrase. So that should be me and
that should be my tunnel. So now, actually let me go back. I can’t do that. So what that, yeah,
that’s tunnels and that’s set up. So local host in Port 80 will
go through to the master node. So if I go to the browser,
And local host, there we go. So we can see there
the dashboard here. I haven’t got anything
running on it. So it says there’s I think there’s,
yeah the master node and then five of these nodes. So there’s six nodes in total. There shouldn’t be
anything running on it. No jobs and so on. So really just the point
of this demo was you see, what was there literally four
steps there and a few minutes. Type in some configuration, and then
probably that’s still going, and a few more minutes I
will have the cluster and this is also a completely,
it’s all the open source stuff, we’re not reinventing the wheel. You can use exactly the same tools,
technologies and so on supported by the community and
available by the community. But we’re just really making it
super easy for you to deploy and manage on enterprise grade Azure and
infrastructure. So that’s where I’m
gonna stop on ACS. As I said, tomorrow there’s a deep
dive into ACS, so if you really want to get it in containers,
please, please attend that. Should be good. So that’s it, we’re out of time. Thank you so much for your time. Yeah, it was great, thank you.>>[APPLAUSE]
>>I can stick around for questions, and I’m in the ask
the experts as well. So anything Azure,
feel free to come down. I think there’s appetizers,
might be some beer. I’d be pretty sure there’ll be
some beer between 6 and 7 o’clock

2 Replies to “Build microservices and container solutions using Azure Service Fabric and Azure Container Service”

Leave a Reply

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