Continuous Delivery Foundation Ortelius Project Meetings, 24 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: DeployHub's Catalog in a Hybrid Environment

Description

This demo shows how Ortelius, the DeployHub open source core, manages microservices and monolithic components across hybrid environments.

A

So, thanks for stopping by and and checking out, uh deploy hub, one of the things we're going to do is we're going to walk through how we manage microservices and also talk about how we reach back into hybrid, as well as more traditional, which is now becoming termed legacy. Architectures. You know, monolith type applications.

A

So, um let's get started with uh the domains, so one of the things that we uh provide in deploy hub, which is based on the ortelius project artelius, is the open source project and we'll be focusing on uh the open source uh features today that deploy hub was built upon.

A

So in the domain hierarchy, we take a look at how applications are put together based on a domain driven design. So in this case we can see that we've have several domains here. So each one of these pieces is a domain in our domain hierarchy, and this allows us to categorize and organize our microservices as well as our application. So here over in the hipster store, which is our front-end application, that's actually doing the consult consuming side of our microservices.

A

We can see that we have the the dev test, broad hierarchy, that we normally see in a waterfall or traditional approach.

A

Then we have like our purchase, processing and our store services, and this is one of the domains that we're grouping together um additional services that we've broken out into a little bit finer grain services, because what ends up happening in the microservices world is we end up having lots of services if we think about how we organize or create a user profile um service, uh we'll have a get a get service for the user profile and then we'll have a servicer dealing with the update um the delete, uh those types of transactions as well.

A

uh So we'll group group those in uh to like the shipping service, for example. uh So those microservices are organized under purchase processing in the in the shipping service category. And then we may have another team that may be working on just the store services and they'll have their breakout as well. Where we're looking at product catalog recommendation some cart services and ads service as well.

A

So the domain hierarchy really allows us to structure how our services are organized and this is going to span across multiple get repos. So what we're doing here is breaking down the barriers, the business silos and really looking at. How do we organize and find our services in a domain driven design and put these services into a catalog, so we can find them. So not every team is going off and writing a single sign-on routine.

A

We are able to categorize a single sign-on, maybe like in a security service domain, and that would then be utilized by all teams within the company, and this is really important, because if we look at it from the the get side, the git repos are typically organized just based on uh the organization level and then the repository name. So the get repositories are really uh on the flat side, which makes it hard to navigate and find things deploy.

A

Hub and ortelius are going to break down that barrier and give us an extra level of of organization that we need when we're dealing with microservices from there. Let's go ahead and take a look at how we're going to uh be placing our services into our catalog.

A

So let's go ahead and go into one of our application versions and we'll take a look at on another view of our domain hierarchy so over here we're looking at the domain hierarchy and we can see again our purchase, processing our store services and within each one of those we're going to have our individual services here. So we can see for shipping services.

A

We have many different versions of a shipping service that we want to consume or possibly that we can consume, and this is where we're laying out the relationship between the service and a version of our application. So in this case we're looking at the fourth of july sale, the 97 version of that and which services are being consumed. So in this case um this one's consuming version 17 of the service.

A

uh If we just want to replace um 17 with the latest one, we could just do, drag and drop and replace- and that's how we can update that. uh This blueprint can also be driven from a configuration as code aspect where we represent this in a yaml file. uh Basically saying these are for this version of our our hipster store.

A

These are going to be the services that we're going to be uh consuming now. One of the interesting things that we're able to do with deploy hub and artelias as part of the your ci cd process is really take a look at and hook in and get a base view of the services and how they're being consumed.

A

So once we have a base starting point, we can then from there on out, based on our ci cd process, start maintaining this automatically, but we need our first starting point, which are is our base version and then from there we'll recognize throughout the cdci process. What's happening.

A

So if we add, if we do a build and we get a new version of the the ad service that will automatically create a new representation of the ad service in deploy hub and then will automatically create a new version of the application based on that new service.

A

In this example, we're just dealing with about 11 or 12 services. Typically, we are hearing. Most applications are built up between 50 and 100 servers for an application.

A

Now, when we look at multiple applications at a company where the let's say the checkout service here is shared, we'll see that multiple application teams are now consuming uh the service.

A

So let's go ahead and look at it from that viewpoint, where we're going to flip the the lens that we're looking at and we'll take a view of, let's say the cart service here, who's consuming it.

A

So in this case we only have two versions that are consuming this version, 248 of our our our cart service. So we can take a look at because we're tracking all the different um relationships. We can switch our lens to see how um who's, in this case, who's consuming me in the previous screen. We're looking at what am I consuming from an application standpoint again we're going to dive into the your ci cd process. So when we deal with a new service, that's coming along we'll.

A

Actually, um we add a step to your ci tool, whether it's can be jenkins or circle, ci or or team city, and you know we fit into all those the the ci tools and when we go through in this case this was done. This is built from circle ci.

A

We recognize that there's a new commit that triggered the build, and when that commit was uh triggered, we actually created a new docker container, a docker image.

A

So here is our new docker um sha that we kept track of and the and how is tagged in our in our registry.

A

So this is what we're grabbing automatically out of our our ci process and then the next step is where we again look at how that is going to associate up into a version of the application, and once we have that relationship the base, application version, just defined will automatically maintain that and then, when we go to deploy we'll pick, which version that we want to deploy and we deploy to an environment.

A

So in this case I have several different environments. I have a our hipster store cluster, then a couple qa environments. So when we deploy we're deploying to an environment, an environment is actually made up of multiple endpoints. um If we need to so at the environment level, we can actually take a look at from this standpoint of what's been deployed to it.

A

So in this case we could actually see that, based on these boxes here we have two different versions that have been deployed to this uh to the same environment.

A

Now some of the things that we get into because we're managing these relationships, we can actually start asking questions about okay, I've deployed to the qa3 environment and the qa4 environment. What's the differences between those two environments- and we can say okay between qa3 and qa4, we have two different deployments that have happened and we have some uh config pieces that are happening so our deploy environment was those two.

A

We have a different uh pipeline that happened to do the actual deployment and if we go down we'll see, what's actually different between these two so so far, everything's the same and only difference that we're going to have is the the basic environment and the application version.

A

So, in this case, we have version, 97 was deployed to the qa4 environment and we have an older version over in the 10.6 version was deployed over to the qa 3 windows environment, so we'll also track not only the components that are being deployed, but also uh configuration, uh that's that has been done at that level.

A

So it makes it very handy for us to answer the questions of you know. What's changing, we can also compare between the two different versions that have been built. Let's look at what's changed at that level. We can see that at this level we ended up with a new git commit and a new container at that point. So if we had other uh information about uh the configuration changes between components, we'd be tracking that as as well also, we could take a look at it from the application standpoint.

A

Let's pick, let's go to those two versions and compare those and we'll look at the differences between 94 and 97 here and we can see at this level. The only thing that's been changing is the cart service. um One of the things we do with artelias and deploy hub is we we execute deployments incrementally.

A

So in this case, the only thing that's happened between those two application versions and where they were deployed to is. We were updating the um just this one cart service version uh looks like everything else was the same.

A

So with this we're really focused on how an application is put together, how where that application version is being deployed to and then tracking the differences as it moves through the pipeline.

A

So in this example, we've been just looking at a couple: qa environments uh and a uh a cluster uh that we've deployed to, but we can also look at buildings out into a full pipeline example, where we have dev environments or multiple dev environments, and we have multiple qa environments, and then we have our prod environment that we may have like a staging prod environment and then our regular uh full production environment throughout the whole process, deploy hub and artelius will be tracking everything.

A

That's happened and we'll be doing an audit control of exactly what's being performed at the different levels. So we can actually see at this level everything. That's happened whether we've done an attribute change, we'll look at the deployment log. We have a full history of what actually happened at the deployment level um in this case. Just that cart service that we're looking at was the only thing that changed uh that went out to the the cluster in this example.

A

So with that, that's like a a a quick view of what we have going on with uh with deploy hub and let's go ahead and open it up for any questions that you guys may have.

A

So if you guys want to give this a try, we do have a sandbox. So if we go to deployhub.com and from here get over to that site, we can sign up and what we'll do is go through the registration process right here and what will what the end result will be? Is you'll get an email and you'll get a full application um that we've kind of bootstrapped for you, so you'll hit see the hipster store uh process.

A

uh I mean uh application and components out there and you can go ahead and deploy this, so you can pick a version and um that we supply with you is sample data and you can pick deploy when you deploy you'll only see the hipster store cluster, the other two I've set up just for this demo, but you can deploy to the hipster store cluster.

A

Now, one of the interesting things that we've set up with the hipster store cluster is it's actually being deployed out to gke, where we have our our our demo cluster that's running and we have a pre-action out here: we'll actually go out and resize the cluster, uh so the deployment is um hits the cluster uh off and running. So um this is a pre-action.

A

We take down the cluster every night and so the next time somebody comes through and does the deployment we go ahead and resize it as a pre-action uh at that level. So go ahead and sign up um we'll give you that sandbox, if you run into any issues with the the sandbox just uh give us the email and we'll help take care of that uh with that process, um like I said when you do, the sign up, you'll get an email, uh giving you the links and stuff to get you going.

A

So any questions, let me see if I have get to the chat here.

A

A

So we answered that question, um like I said, uh if you're interested in the artelius project, which is what um deploy hub is based upon, uh that website is going to be.

B

Everything is free.

A

Ortulia- and here you get information about um what the ortelius is, how to get to the the github project and if you want to join the github project, we can get you set up on that front. There's uh information about how to uh join the open source project in at the at the readme level here.

A

So, if you look at the arteries project, uh we'll have the readme that says how to get started and all that all those pieces as well.

B

um Hi uh steve this is vlad. uh Thank you very much for this uh presentation. It was very useful. I have a small question about environment level. You mentioned that environment level uh includes several endpoints.

B

Is there any limitation on the number of endpoints which may be in any environment.

A

No, you can have one of the interesting things when we look at an environment is an environment is going to be made up of uh different endpoints. So in this case I'm using one of my uh global um local host endpoints and you can set as many uh servers for that endpoint. That you'd need so, let's say, and you can mix and match, um like. I said earlier uh in this demo, we're looking at just microservices and deploying containers to a kubernetes cluster.

A

But let's say we wanted to deploy not only to kubernetes but also a database change. We would add a database server as another environment, another server to our environment, and when you work at the the individual endpoint level, we can actually assign it a kind of like a roll to the endpoint. So this one has two different uh uh is looking at being an application server, as well as managing uh the kubernetes kubernetes uh in the kubernetes world.

A

We actually are kind of doing like a jump box type of um uh access because we have actually the local host is connecting to the kubernetes cluster. You don't really like log in directly into kubernetes cluster, so we go to the local host and can configure that local host to connect up to the right cluster running in any cloud provider. So you can mix and match cloud providers at that level. But with this um this endpoint definition, if we added a new endpoint for the database server, we can tag it as a database server.

A

And when we have a component, uh that's for database change. We can actually route the database change to the database server and route, the kubernetes change over to the kubernetes endpoint. So when you build up your environment, you may have a hybrid world where you have some transactions that are in kubernetes.

A

I mean some some services that are kubernetes. You may have more of a monolith piece that that's running like tomcat or wild um jetty or you know websphere, and then you may have your database piece. So you can actually combine those three different types of endpoints into a single environment and when you deploy we'll go ahead and route to the right right components to the right endpoints. I know there's a long answer, um but just want to show you the flexibility that we're able to perform with with deploy hub.

B

Thank you very much steve. Thank you.

A

A

Any other questions.

A

Pull up chat here, nope.

A

And then, when we look at um uh applications as well, you can have as many applications defined. um We have we look at on the licensing perspective. We have two. We count uh the base application version, so in this case we have the fourth of july. Sale is one of the base, application versions and the labor day sale on the base application versions.

A

Like our our starting point um from there like, I said we can start once we get that base definition, we'll um the ploy hub and artelias will start maintaining that automatically for you, through your, whether it's going to be jenkins.

A

We have like a jenkins plug-in, uh also a jenkins groovy library, um and that's where we'll start maintaining uh that your application definitions and these versions going forward for you automatically.

A

Okay, well, thank you, everybody for stopping by and taking a look at, uh deploy hub again. What I showed you today was all the features that are in the ortelius project. uh Some of the things that are the playhub specific are going to be around release management managing releases and releases are deploying multiple applications.

A

At the same time, environments in the deploy hub world, we have what's called smart calendar calendaring, which you can set up deployment schedules and release planning around that, and then also when we get into um like the setup, we can define users in the deploy version against ldap servers that type of world. So there's some more flexibility in users and groups in our in deploy hub versus artelias, but everything we did today was based on the open source project ortilius.

A

So go ahead and sign up again just go ahead and hit the the deploy website and what ends up happening is: will you be using the sas version of deploy hub? That is that we've been looking at today and if you want to do on-prem, that's available as well. If you look at the user guides, which you can get to from the the readme pages, the user guides will show you how to install locally in your own environment.

A

Again, thank you for stopping by and if you have any questions you can reach out to me. uh Email's real, simple, steve at deployhop.com and I'll be uh happy to answer any of your questions and also um we will be on the chat in devops world. So, if you want to ask any questions, just come to our booth and we'll be on that chat session there as well.