What are Diego and Lattice, and how do they fit into Cloud Foundry? Andrew Clay Shafer and I discuss just that in this episode, as well as the last video game we remember playing before, you know, we got busy.
As you can tell, Lattice gets kids and dogs really, really excited and we think you’ll start yelling about it too after listening.
PLAY EPISODE
SHOW NOTES
- Subscribe to the feed for Pivotal Conversations.
- Feedback: podcast@pivotal.io
- See Lattice.cf for all your Lattice needs.
- Cloud Foundry Summit presentations by Onsi Fakhouri:
- Introducing Diego at the Cloud Foundry Summit 2014 and then
- Diego Update 2015 (includes Lattice talk)
TRANSCRIPT
Coté:
I have a theory that people who used to play video games a lot, they probably remember the last video game they really played like it’s this monumental switchover. Let me test that theory out. Do you remember the last game that you really played or the era of games you were playing?
Andrew Clay Shafer:
I’ll bite. I say yes. You want me to tell you what they are?
Coté:
Like I can tell. The last video game that I really played was maybe this was five, six, I don’t know how many years ago but there was this game Left for Dead that came out. I think I played two of them and then it was gone. That was it. That was the end of the line.
Andrew Clay Shafer:
My favorite genre of game is real-time strategy games and there’s a few phases there. I can go for some first person shooter every once and a while but I really like the complexity of the real-time strategy games. Back in the day, the StarCraft and the Age of Empire games were pretty fun.
Coté:
Your resource allocation and universe takeover type of situations.
Andrew Clay Shafer:
It’s all about the competitive advantages but there’s all these ones, balances of power for the different… Playing one more game you’re talking about and the build-out phase and the types of maps herein, there’s all these new ones and it’s just… It’s fun to play with the complexity.
Coté:
Yeah, I used to get crushed during those games because I didn’t have the long term stickiness to figure out the strategies to do and I was too slow. I would see the experts who would this game and all of a sudden, they’re whacking down the forest or mining the moon rock or that they’re doing stuff.
Andrew Clay Shafer:
Have you ever seen the videos of the Korean leagues where they play the… It’s the actions per minute videos where the… It’s other worldly to watch them play StarCraft.
Coté:
They measure it in actions per minute? That’s fascinating.
Andrew Clay Shafer:
To be competitive, you basically have to be 300 actions per minute. That’s ridiculous.
Coté:
That’s a good baseline, speed. It matters in video games.
Andrew Clay Shafer:
Another game I used to play a ton is the standup fighters, the Street Fighter genre. That was good time, back in the salad days.
Coté:
Changing topics only slightly. I don’t really know why it’s only slightly but both of us have been traveling around quite a bit so it’s been a while since we recorded but I’ve been saving up an exciting topic for us to talk about and that is the wide, exciting world of Lattice and Diego and the Elastic Runtime and one of the core components of the Pivotal and Cloud Foundry world. Was it in the Interop that you had a day-long tutorial thing or something like that, I forget which conference it was.
Andrew Clay Shafer:
It was the container thing. It was three hours so half a day.
Coté:
You actually had a three-hour tutorial over this session which I had a nice forcing function of causing you to get very hands on with something like Lattice. It seems like you’re perfectly positioned to explain what’s up with Lattice and seem like a nice topic for us to go over. Why don’t we start at the end? Why don’t we start with Lattice and what that is and we’ll work backwards to where it’s from. Actually, there’s a couple of good presentations from the previous two Cloud Foundry Summits going over how Diego came about and then how Lattice came about. I think it’s… What I’m most interest in talking about is what the intentions of Lattice are at the moment. Who’s it focused on and where does it really shine, if you will?
Andrew Clay Shafer:
The presentations you’re referring to are from Onsi Fakhouri who is basically charged with all Cloud Foundry… All the people of Cloud Foundry engineering right now rolls up to him from engineering perspective and he gives really great presentations. He puts a lot of plot into them and they’re really fun as well. What Lattice represents is essentially taking the components of Cloud Foundry’s Elastic Runtime… rewriting every part of Elastic Runtime and letting them stand alone as infrastructure component without the rest of Cloud Foundry.
There’s probably more than one “demographic” but in Cloud Foundry, it’s a big pill to swallow. Cloud Foundry also has features that are perfectly sensible if you’re trying to manage a lot of developers, hundreds or thousands of developers managing the projects and the workflows and the role-based access to resource that don’t make any sense at all if you are three-people in a dorm room at Stanford or whatever the kids are doing these days to build their startups.
We decided through a series of things and we also… It not being that much extra work to pull this, tease this bit apart and put a API, they’ll allow to talk directly to the internal bits of the container scheduler and it also has dynamic routing for the request so that as you add and remove the instances, they get the right request and because you care so much about operating this thing on the second day and forward, there’s log aggregation.
It’s the Cloud Foundry scheduling with the routing and log aggregation packaged up with the installers that make easy to get started so you can go get… In an hour, if you have some familiarity with this technology, have EC2 accounts, you can have running Lattice cluster in an hour following just the instructions on the Lattice website.
Coté:
The consequence is… To make it explicit, is that you can have a very Cloud Foundry experience without having to run all of Cloud Foundry essentially.
Andrew Clay Shafer:
There’s a little bit of nuance here because the Lattice user experience is very different than the Cloud Foundry’s experienced. Lattice doesn’t have all the build pipeline, buildpack stuff. Cloud Foundry has a bunch of things about workspaces and organizational… You have role-based access to resources that you’re developer self-service access to from this administrative perspective where at Lattice is just everyone has cluster root. You’re on your own to build your images. You’re on your own to make other decisions that Cloud Foundry does for you but you can take for granted in the full Cloud Foundry but it’s an interesting cluster schedule that gives you the ability to scale up, scale down, recovered from failure… The type of stuff that you’d want to do if you’re building web scale web infrastructure with packaging a stand-alone. Easy to get you started.
Using it as an infrastructure but one of the things that’s accelerated internally and why people are excited about it is the ability for us to do work on these components ourselves. There’s been quite a bit of pick up in the Spring community because we have the overlap with Spring team where they’re excited to be able to do some of the things on Lattice that… Cloud Foundry and the cycle to do the full job of buildpack is not as… It’s not as quick as feedback loop. We working on some of that stuff as well but just to throw together a cluster and see how a real distributed system will behave under certain circumstances, it’s a nice infrastructure to that and work through that architecture or the interactions that you want to have for your new-fangled microservice that you’re building.
Coté:
To rephrase it a little bit, essentially, I just had the kids in their dorm room, whatever, they can basically define here are the containers that we want to run. We put can put whatever we want in those containers. Lattice gives you the ability to… It basically run your containers in a clustered mode and it has the minimal stuff you would need to manage that.
It has a logging in it and obviously, I mean not obviously but routing in there that you would need to figure out which actual running container you want request to go doing things like but it doesn’t necessarily have the whole… As you’re saying like the build chain process. There’s maybe not the same command line interface that you would have or you’re sucking in the source code or an artifact of a project that gets stuck into a container for you and more fully managed by the full on Cloud Foundry experience.
Andrew Clay Shafer:
In Cloud Foundry, you would do cf push and then depending on the flags or the director you’re in, you’ll figure out what bits of code to push that gets pushed into the Cloud Foundry build pipeline which is going to do the logic for the buildpacks and that’s going to determine, “Okay, if I push the jar, it’s obviously Java. If it’s the rb files and it’s ruby and there’s some logic that figures out what buildpack.” Then that all gets layered on and eventually, that creates a container and then that gets started in Cloud Foundry wherein Lattice, what you specify is the name of a Docker container and it just pulls the named image from the index on Docker help or you can have a private registry and then that gets started.
You’re on the hook for whatever that build process is and however you do that is up to but you just specify the name of the image you want to run. You cancel, there’s a bunch of flags for how many of the instances you want to start and what size that should be and that kind of stuff, just all the boxes, they’ll do sensible things.
Coté:
How would you categorize this? Is it like an in development and experimental thing or production-ready thing or just a project somewhere in between all those or… How would you label the stating of it?
Andrew Clay Shafer:
This is an interesting topic on its own right and if you look at these other… I think if you just look at the landscape, by now, you compare some of the stuff rises during too but things that you’re seeing in the Kubernetes or Mesos communities with a little bit more emphasis on the workflow developer user experience, maybe a little less infrastructure centric but it’s… All those projects…we’ll see how that evolves. They’re pretty vocal that leaves our preproduction data projects right now and I’d say that Lattice as a packaging of Diego which we are every day closer and closer to running as our production, deployment of Pivotal Web Services and Pivotal Cloud Foundry, getting hard and… I think it’s by certain measures and everyone has a different understanding or idea about what’s appropriate for production.
These are the same components that we run into the Cloud Foundry right now and Pivotal Web Services right now. If you know the secret flags, you can deploy to Diego on Pivotal Web Services today and it’s only a matter of time before when someone decides to take the marker or whatever that it says it’s production ready but if you have the understanding of what these components are, there’s definitely people, there’s some projects that I know right now where people are running Lattice as their production for structure.
Coté:
Right, using a minimal cluster management for containers basically.
Andrew Clay Shafer:
It’s minimally valuable cluster management and it will evolve. There’s a backlog for Lattice and those are mostly public back up so you can so where things are going but you’re going to have a little more of a… There’s going to be… In conjunction with the cluster management, some of the build pipeline functionality of a Cloud Foundry but it will be pulled out as a separate utility so there’s… This is one of the things that I think looking at Cloud Foundry’s landscape and the evolution of that because it’s such a big pill to swallow that it makes it a bit overwhelming for a small team or an individual developer to get started and by decomposing each of those components that make up Cloud Foundry and making them individual leaks accessible then I think that will stimulate the conversations and the adoption in the community so the Lattice is one of the first attempts to decompose that and there’s a project that’s on their way that will do a similar thing for some of the build pipeline.
Right now, in Cloud Foundry, you’ve had container orchestration since 2011. It’s been container-based not quite from the beginning but in the early days and that’s just… Part of that comes from the people working on it had been guru engineers, behind the veil of guru they’d seen how that stuff worked and they’ve chosen and weened themselves with that having the context. Now that everyone’s excited about containers, we’ve still been doing this stuff, it’d be nice to break it apart in a way that’s more consumable so people realize how that works because when it’s all one big pill, you have to swallow altogether. It’s harder for people to see the ins and outs of it. While Cloud Foundry is a much more complete solution compared to some of the other things people are using or starting to use for their platforms, it’s less accessible. That drives or inhibits the conversation about how some of those stuff works.
Coté:
I think it also… There’s a learning from the Java enterprise days where you did have a gigantic big ball of stuff. When people came along, notably Spring folks and other people and decomposed it into usable parts. I don’t know, in my opinion, it was a lot more friendly and easier to understand the whole if you could pull off right the bits of it instead of being forced to use everything at once. Obviously, there’s a lot of power to use a metaphor you’re always using and having a Death Star. Sometimes, you need something a little smaller before you upgrade to the planet killer.
Andrew Clay Shafer:
Sometimes, you just need a space shuttle.
Coté:
Exactly. Before we get into how Diego and Lattice is related. Before we get to that… You eluded to this but what… If someone’s looking to start to understand and get involved in Cloud Foundry and doing cloud application and the containers, do you think Lattice is a good place for them to start or should they start with something else? Who should be looking at using Lattice?
Andrew Clay Shafer:
I think that if you are an organization that fits the criteria of “enterprise,” there are bunch of things in Cloud Foundry that you are going to need to reproduce to take advantage of whatever solution you’re going to choose if it’s not Cloud Foundry. If you are going to manage hundreds of apps, hundreds of developers, there’s no point probably… Depending on what you’re trying to do obviously context matters but that workflow support and the role-based access to resources is one of the big selling points from a Cloud Foundry of perspective. If that’s your context, that’s what you need then I probably would avoid Lattice. Except if you want to build your own light-saber, you want to build your own light-saber, knock yourself out.
Lattice is going to more interesting to small teams with high trust where everyone has cluster root. Everyone’s going to be… When you think about Lattice, there’s no authentication. If you’re able to talk to the API, you can basically do anything you want. Cloud Foundry has a much more rigid policy-driven structure around who can do what and that’s an important thing that you’re going to want to have in place if you’re imagining these large teams and lots and lots of applications or if you’re building a single service or some sort of microservices for your startup and it’s only you and everyone has the root password anyway again, Lattice is a great way to get some of these power and flexibility.
Coté:
Also as I’ve been looking at Lattice and I don’t know… Watching it evolve a little bit, it also seems to be… I’m forcing this notion on to a little bit but I’m always aware of how the idea of open development, whether it’s open-source development or doing development in the open, is evolving and changing. Developing an engine, if you will … Something in the infrastructure layer is hard to get to a point where you can demonstrate user value. I’m always joking like, “Hey look, now we’ve got a blinking cursor.” We just configured a bunch of stuff that doesn’t do anything. One way that I’m thinking about now as you’re going over that is something wrapping Lattice around, this other engine that we’re developing. It gives the process just developing everything the chance to get more exposure and be road tested. Very similar to… You’re eluding to…
One of the more interesting ways is that we test out and perfect our code is that we’d run it ourselves in Pivotal Web Services, right? A lot of the things that we’re working on or running up there and you can turn then on or turn them off but it gives us the chance to run them before we actually give them the customers. In a similar way, I would hope that even though Lattice may be… It may not have all the enterprise features that you would need all the controls and all that stuff you’re going over but it is a way to participate in the evolution of this engine that we have at the bottom that’s not just working those weird chunks of code and getting up to blinking cursors and things like that.
Andrew Clay Shafer:
Absolutely and one of the things that is happening and this is across the industry but Cloud Foundry is definitely part of this evolution is just experimenting with the best way to do this. Inside of Cloud Foundry and trying to provide a package solution, it’s harder to do those experiments that Lattice is allowing us to do right now.
Coté:
Yeah, exactly. I used to always joke that it’s very hard to be an industry analyst covering Cloud because it’s like not you’re going to be running multiple clouds and all these giant data energy you have in your back pocket. Just having the lab, if you will, the testing’s out as you develop them can be challenging. That’s a nice side effect.
Andrew Clay Shafer:
There’s a bunch of many unanswered questions about what’s the best way to do service discovery. What’s the best way to do routing? What’s the best way to do… Right now, in Cloud Foundry, the way it was designed out of the box, there’s routing, dynamic routing but it’s only for HTTP. What does it mean to have IoT protocols or going to be dynamically routed to these back ends? Well, we’re figuring that out as we go.
Coté:
Getting to the other part we’ve eluted to a lot, we have Diego which is essentially the rewrite of the elastic runtime and the evolution of it that runs and… I don’t know what we call it internally but runs inside regular Cloud Foundry, if you will. You’ve given hints about how will it release the Lattice but how does that… How would say it fits in with Lattice or overlaps with it?
Andrew Clay Shafer:
Well you know how much I like the word “PaaS.” I just love the way that rolls off the tongue. The elastic runtime for all intents and purposes is that Heroku inspires platform as a service. Diego, if you go back and revisit Onsi’s presentation, was a rewrite of few aspects of the elastic runtime… Basically, you count for some of the lessons that we learned running this stuff in production. It’s not that it doesn’t work or didn’t work, it’s just that you learn things as you go.
If you go watch, and Onsi can articulate this, much better and he did that and you can watch it. It’s 20 minutes of your life that will be well-spent. He’ll explain why we wrote a bunch of components from Ruby and to Go and why we chose not just do ports from Ruby to Go but actually revisit and restructure the architecture in the meantime and that is enabling a bunch of things… One of those which I think is interesting and important is in the originally envisioned Cloud Foundry elastic runtime, we had a… At least the two have the container-based orchestration, you had a Linux containers but there’s a lot of very Linux-specific logic and Linux containers specific logic that was embedded in the process and as the pressure to support Windows and then the Iron Foundry project merge in the community but what you had to accomplish that was essentially going through these Linux-specific bits and doing and if Windows and do this other thing, walking through and trying to find where all the logic was.
What Diego’s done which is I think is very meaningful and it allows you to move very quickly is provide a very clean abstraction over the life cycle of those processes that can then be applied to any back end. Right now, we’ve got Windows working. We have the ability to do the Linux containers. You could also, if you’re so inclined, imagine making that work on Solaris or any of these other types of things that support that, that life cycle with the process.
Coté:
It essentially opens up Cloud Foundry to support all operating systems. Assuming you do the work to have them supported but it makes it much easier and possible to run various types of OSes in there.
Andrew Clay Shafer:
You can imagine… One of my favorite topics that you can even have Diego scheduling unikernels at some point.
Coté:
Tasty. Just like you said, you can have Solaris where you get HP-UX in there, just go crazy.
Andrew Clay Shafer:
If you can map it to that life cycle and then put the code that has the API for Garden, then you can run Diego to schedule the workloads.
Coté:
It also seems like with Diego, there’s a host of renaming that goes on or different concepts. Is that just internal project things or is that fundamental renames that are happening of components?
Andrew Clay Shafer:
I’m not exactly sure what you’re talking about. There’s definitely names that changed. I think some of the things change because when you went from one architecture to the other one, the new components appeared and old components disappeared. As a consequence, what do you call this thing and we developed words and jargon for us to talk to each other about it and weR#8230; They’ll always do the best job in our conversations explaining that to the outside world but it’s really just about there’s this thing, how is this responsibility and you try to give it some meaningful somatic name so that you can have those conversations.
Coté:
To your point, a lot of that jargon is internal use, right? From the outside, it operates pretty much the same as you would expect. You have the same interaction of pushing applications and messing around with tiles and services and brokers and all that stuff. It’s the internal workings as they get redone be as you say. Developers like to come up with new names for things.
Andrew Clay Shafer:
Like Diego. Diego has an interesting… The way that Diego got named is the original Elastic Runtime have this metaphor around Warden and DEA was the name of the Droplet Execution Agents. These are essentially VMs that run the containers. The containers are managed by Warden so it’s… Whatever: a prison system. That was already in Ruby and they wanted to rewrite and go and the… It’s the DEA and GO and now, became Diego and they just started calling Diego.
Coté:
Like you’re saying, there’s this… Onsi has a great overview of this but there’s essentially the idea of long-lived jobs and tasks and all sorts of other metaphors that are in there that actually… For as much as we like to make fun of how developers name things, there are some very normal naming conventions in there which is always quite welcome.
Andrew Clay Shafer:
This is the thing that I’m realizing more and more, seeing how the receptor API and Diego actually works is that what has been built is actually much more forward leaning than Cloud Foundry’s functionality is actually be able to take advantage of. The original scene was basically on running the web ops and then now, we’ve added the ability to do these one off tasks but you have… It’s quite sophisticated scheduling capabilities and I’m excited to see how that evolves. The buildpacks… We basically got rid of components in Diego because Diego is so good at interpreting arbitrary computation that you got rid of and distributed these other components into simple tasks.
Coté:
You’re also saying there’s a… Separating out the build pipeline. What’s going on with that?
Andrew Clay Shafer:
There’s a few things who are driving that but there’s… One is to just make it an interesting tool in its own right but if you know what’s happening with things like our CI evolution with Concourse and things are happening across the industry, then the idea that code is… The deployable artifact is shifting to this world where the deployable artifact might be a fully-packaged container. We’ve seen that in certain different ways and that’s where Lattice takes because you specify the container image that you want to run and what I would like to see, and there’s a few different ways that people are interpreting this right now, is that you make deploying containers a first-class artifact.
You’d have a bunch of sophisticated hooks to be able to do… Types of containers in a…that you’d like to do to make sure that those are better and then you move those containers as an artifact through the process. By breaking that out and making that a first-class tool and then we were also… We aspire and this is also… Impact if there’s a new announcement which we could probably do a podcast on as well around the open container project which is I think going to be very, very beneficial to a bunch of things but particularly, Cloud Foundry which will give us a nice standard container runtime and special occasions around, how are you going to handle the images and metadata of the idea… At least before that became an entity was to be able to manifest the buildpack.
Take the buildpack pipelines and create Docker images, Rocket images, Droplets or whatever you needed to for whatever your product was but how about be a single standard phase on the one end that would take advantage of the buildpacks and then give you whatever the output was as a deployable artifact. That’s evolving and if… We’re probably moving in the direction of adapting runC as a standard container runtime and then that would have… As an open-source strategy with the Cloud Foundry Foundation and the backing of the Cloud Foundry ecosystem, we should have a pretty nice tools to be able to make those open container standard images.
Coté:
That makes sense. It’s long term. Well, I mean it’s happening at the moment but long term, you can see that there’ll be some nicely decomposed services that make up Cloud Foundry which models the way we encourage people to think about how they actually write their applications that we’re on top of Cloud Foundry.
Andrew Clay Shafer:
In a sense that Cloud Foundry had some… It’s microservice already but it wasn’t really written or the projects aren’t set up in a way that it was easy for you to set up, utilize, understand. Some of these just a functional documentation while each of these components can do individually. Why this represents work, it’s already done, was in place but just putting in a little [work to give it] its own installation mechanisms, given its own documentation, make those APIs that were buried in the code, explicitly documented.
Coté:
That makes sense. Before we wrap up, since you did a hands-on workshop around this stuff, can you walking us back to Lattice, can you walk through the steps of, I don’t know, a hello world with Lattice, like what is… It’s always better to see a demo of it but what is it going to feel like to get it up and running and deploy something and actually see a result in a very simple test run?
Andrew Clay Shafer:
What I did in [the talk] was basically start with this explanation what containers are because I think there’s a lot of confusion in the market. The first part was pure presentation and I just explained a little bit about how the kernel works and what namespaces do and what cgroups do and walk people forward to the tooling that you have in place with things like lxc and Docker and that evolution. I also had our good friend, John Willis, and so we did some demonstrations of Docker and showed a bit about how that works and then with Lattice work…
I already had the last cluster set up… If you never done it before, it might take you an hour. If it takes you longer than an hour, send me an email and we’ll make you take less – but it’s not that bad and I can get one up on this thing to now in about five minutes as far as the network and the VMs can start. I push an app into it and show… Usually, I just start off by pushing a little app in to the Lattice and I say… There’s a nice visualization thing that we [a console] called X-Ray that shows you all your cells, basically your capacity and then each one of the deployment size visual representation of that app and you can hover over it and that gives you a link to it because it’s connected to the routing and I showed people… I just started this app, you saw it just start, there’s a URI, you can hit it and then I open up the logging and I show that there’s routing and request logs for what’s going on and then I started another app or I don’t start another app…
First, I scale the one up and down so it’s like, “Okay.” Now, I have a single instance, well what if a machine failed or what if that processor had a problem, now I’m down so then how can I add instances and there’s this one command and it takes literally seconds and now, you can see those other apps come on and you could see their… In the logs now when you make a request then that is reflected in the logs and hit that instance versus the other one, then I do build up where I had so more apps so you can see this visual representation of the layers and you can see all the scheduling works as you scale them up and down and they’re getting evenly distributed across yourselves and talk a little bit about the logic of the option and make sure that you don’t have more than one… It will never schedule more than one of the same app on the same cell until all the cells have an instance of that app.
That’s how they load that way and then the closing climatic ending is I’ve shown you routing, I’ve shown you the logging, I’ve shown you scaling and I’ve shown the orchestration and action and then I will go to the EC2 console and I’ll delete one of the VMs. Also, it’s actually…but it’s like your capacity planning is… I don’t schedule more applications on to them when I know that the remaining ones can handle the application instances because you can imagine you could’ve… Fail your capacity with…and in failure capacity and you delete some of your capacity then you obviously under capacity. If you leave a little bit of a buffer, then you delete one of the virtual machines and Diego scheduling algorithms will notice that they’re not passing their health checks and you’ll see those dynamically get rescheduled on the remaining infrastructure and the whole thing takes literally seconds.
Coté:
You can demo the resiliency of it. Yeah, well that sounds good. Well, we have a site… Actually, there’s a site of Lattice.cf. What country is ‘cf’? I actually never looked that up, that’s interesting. If you go to Lattice.cf, you can get pointers to the documentation, the code and everything. Are there any good, other than the two presentations we’ve referenced previously I’ll put in the show, are there any good references to point people at?
Andrew Clay Shafer:
Honestly, lattice.cf has… We put a little bit of energy into approaching documentation and I wouldn’t say that it’s perfect but just like software, you just keep releasing and we’ll make better and you have documents to get started, you can run it on your laptop as a vagrant thing. You can run it on… Mostly the popular Clouds using Terraform as an installer. It won’t take that long to get either of those things to happen. There’s links to get started there and then at the end of the day, there’s also some examples about different images that we know will work and then there’s some other stuff I can dig up and link to where people like Josh Long have started doing things with the Spring Cloud stuff so you have…
Okay, here’s Hystrics and the circuit breaker stuff and Eureka stuff so service discovery running on top of Lattice. Between Josh Long and others I think there’s a couple of blog posts other there. If your job and clients and particularly screaming clients, there are some great examples with… Using Lattice is the underlying infrastructure to build microservices with Spring Cloud and Spring guru.
Coté:
That sounds good. I’m glad I kept myself a little ignorant. Now, I’ve got a full cup to deal with which is always thrilling. With that, this has been another Pivotal Conversations episode. If you want to check out more episodes and find the show notes, links to all the presentations and what not we’ve mentioned, you just go to pivotal.io/podcast with an ‘s’ or no ‘s’. I think both of them work and then you can subscribe and check things out. You got anything else you want to close out with before we wrap up, Andrew?
Andrew Clay Shafer:
Just say it’s been too long and it’s good to be back in the saddle and we should do… We should have another conversation soon.
Coté:
We’re going to… We’ll be out in the wilds and DevOpsDays here pretty soon so maybe we can collect some interesting field reports to go over, see how people are doing with the DevOps.
Andrew Clay Shafer:
We’re going to DevOpsDays Minneapolis. We should also be in Chicago, Pittsburgh. I’m not sure I’ll make every single one of those but I’m at least giving a talk in Minneapolis and it’d be fun to see people on the community.
Coté:
Yeah, absolutely. If you see one of us out there, some other Pivotal person, it’d great to talk with you and with that, we’ll see everyone next time.
Andrew Clay Shafer:
Until next time.
About the Author
