Listen to the podcast. Find it on iTunes. Get the mobile app. Download the transcript. Sponsor: DigitalOcean.
Dana Gardner: Welcome to the next edition of BriefingsDirect. I’m Dana Gardner, Principal Analyst at Interarbor Solutions, your host and moderator.
The use of containers by developers -- and now increasingly IT operators -- has grown from infatuation to deep and abiding love. But as with any long-term affair, the honeymoon soon leads to needing to live well together -- and maybe even getting some relationship help along the way.
And so it goes with container orchestration and automation solutions, which are rapidly emerging as the means to maintain the bliss between rapid container adoption and broad container use among multiple cloud hosts.
This BriefingsDirect cloud services maturity discussion focuses on new ways to gain container orchestration, to better use serverless computing models, and employ inclusive management to keep the container love alive.
Here to help unpack insights into the new era of using containers to gain ease with multi-cloud deployments are our panelists, Matt Baldwin, Founder and CEO at StackPointCloud, based in Seattle. Welcome, Matt.
Matt Baldwin: How are you?
Gardner: I’m great. We’re also here with Nic Jackson, Developer Advocate at HashiCorp, based in San Francisco. Hello, Nic.
Nic Jackson: Hey, how are you doing?
Gardner: Doing well. We are here too with Reynold Harbin, Director of Product Marketing at DigitalOcean, based in New York. Hello, Reynold.
Reynold Harbin: Hi, Dana. Thanks for having us.
Gardner: Delighted to have you with us. Nic, let’s start with you. HashiCorp has gone a long way to enable multi-cloud provisioning. What are some of the trends now driving the need for multi-cloud? And how does container management and orchestration fit into the goal of obtaining functional multi-cloud use, or even interoperability?
 |
| Baldwin |
Jackson: What we see mainly from our enterprise customers is that people are looking for a number of different ways so that they don’t get locked into one particular cloud provider. They are looking for high-availability and redundancy across cloud providers. They are looking for a migration path from private cloud to a public cloud. Or they want a burstable capacity, which means that they can take that private cloud and burst it out into public cloud, if need be.
Containers -- and orchestration platforms like Kubernetes, Nomad and Swarm -- are providing standard interfaces to developers. So once you have the platform set up, the running of an application can be mostly cloud-agnostic.
Gardner: There’s a growing need for container management and orchestration for not only cloud-agnostic development, but potentially as a greasing of the skids, if you will, to a multi-cloud world.
Harbin: Yes. If you make the investment now to architect and package your applications with containers and intelligent orchestration, you will have much better agility to move your application across cloud providers.
This will also enable you to quickly leverage any new products on any cloud provider. For example DigitalOcean recently upgraded our High CPU Droplet plans, providing some of the best values for accessing the latest chipsets from Intel. For users with containerized applications and orchestration, they could easily improve application performance by moving workloads over to that new product.
Gardner: And, Matt, at StackPointCloud you have created a universal control plane for Kubernetes. How does that help in terms of ease of deployment choice and multi-cloud use?
Ease-of-use increases flexibility
Baldwin: We’ve basically built a management control plane for Kubernetes that gives you a single pane of glass across all your cloud providers. We deal with the top four, so Amazon, Microsoft Azure, Google and DigitalOcean. Because we provide that single pane of glass, you can build the clusters you need with those providers and you can stand up federation.
In Kubernetes, multi-cloud is done via that federation. The federation control plane connects all of those clusters together. We are also managing workloads to balance workloads across, say, some on Amazon Web Services (AWS) and some on DigitalOcean, if you like.
That’s what we have been doing with our star product. We are still on that journey, still building more things. Because it’s moving quite fast, federation is shifting and changing. We are keeping pace and trying to make it all easier to use.
Our whole point is usability. We think that all this tooling needs to become really, really easy to use. You need to be able to manage multi-cloud as if it’s a single cloud.
Gardner: Reynold, with DigitalOcean being one of the major cloud providers that Matt mentioned, why is it important for you to enable this level of multi-cloud use? Is it a matter of letting the best public cloud services values win? Why do you want to see the floodgates open for public cloud choice and interoperability?
Introducing
Cloud Object Storage
 |
| Harbin |
Harbin: Thousands of businesses and over a million developers use DigitalOcean -- primarily because of the ease in provisioning and of being able to spin up and manage their infrastructure. This next step of having orchestration tools and containers puts even more flexibility into the hands of developers and businesses.
For customers who want to use data centers on DigitalOcean, or data centers on other providers, we want to enable flexibility. We want developers to more easily burst into public clouds as they need, and gain all the visibility they want in a common way across the various infrastructure providers that they want to use.
Serverless pros and cons
Gardner: Developers are increasingly interested in a serverless model, where they let the clouds manage the allocation of machine resources. This also helps in cost optimization. How do the container orchestration and management tools help? How does serverless, and the demand for it, also fit in?
Jackson: Serverless adds an extra layer of complexity, because the different cloud providers have different approaches to doing serverless. A serverless function running on Google or Azure or AWS -- they all have different interfaces. They have different ways of deploying, and the underlying code has to be abstracted enough so that it can run across all the different providers. You have to really think about that from a software architectural problem, from that perspective.
In my opinion, you would allow yourself to get locked in if you use things like the Native Queuing or Pub/Sub, which works really well with a particular cloud provider’s serverless platform.
One of the recent projects I’m super-excited about is OpenFaaS, by Alex Ellis. What OpenFaaS tries to do is provide that cloud-agnostic method of running functions-as-a-service (FaaS). This is not necessarily serverless, you still have to manage the underlying servers, but it does allow you to take advantage of your existing Kubernetes, Nomad, or Docker Swarm Clusters. It then gives you the developer workflow, which I think is the ultimate end-goal, rather than thinking about decoupling the complexity of the infrastructure.
Gardner: Reynold, any thoughts on serverless?
Harbin: I agree. We are on this road of making it easier for the application developer so they don't have to worry about the underlying infrastructure. For certain applications, serverless can help in that goal, but at the same time you're adding complexity. You have to think about the application, the architecture, and which services are going to be the most useful in terms of applying serverless.
We want to enable our developers to use whatever technologies will help them the most. And for certain applications, serverless will be relevant. OpenFaaS is really interesting, because it makes it easier to write to one standard, and not have to worry about the underlying virtual servers or cloud providers.
Jackson: The other neat thing about OpenFaaS is the maintainability. When you look at application lifecycle management (ALM), which not enough people pay enough attention to, Serverless is so new that ALM is still unknown.
Harbin: I agree. We are on this road of making it easier for the application developer so they don't have to worry about the underlying infrastructure. For certain applications, serverless can help in that goal, but at the same time you're adding complexity. You have to think about the application, the architecture, and which services are going to be the most useful in terms of applying serverless.
You have to think about the application, the architecture, and which services are going to be the most useful in terms of applying serverless.
We want to enable our developers to use whatever technologies will help them the most. And for certain applications, serverless will be relevant. OpenFaaS is really interesting, because it makes it easier to write to one standard, and not have to worry about the underlying virtual servers or cloud providers.
Jackson: The other neat thing about OpenFaaS is the maintainability. When you look at application lifecycle management (ALM), which not enough people pay enough attention to, Serverless is so new that ALM is still unknown.
 |
| Jackson |
But with OpenFaaS -- and one of the things that I love about that platform -- you are baking functions into Docker containers so you can run those as standard microservices outside of the OpenFaaS platforms, if you want. So you can see that kind of maintainability. It gives you an upgrade path, despite being completely decoupled from any particular cloud provider’s platform. So you gain flexibility.
If you want to go multi-cloud, you can run OpenFaaS on a federated Nomad or federated Kubernetes cluster and you have your own private multi-cloud FaaS approach, which I think is super cool.
Gardner: It sounds as if we would like to see the same trajectory we saw with containers take place with serverless, there is just a bit of a lag there in terms of the interoperability and the extensibility.
Baldwin: There is also the serverless framework they can use that helps to abstract out the serverless endpoints. So abstract at Lambda or Kubeless or any other, Fission; Kubeless and Fission are just two other projects that are more geared toward Kubernetes than others.
Gardner: Nic, tell us about your organization, HashiCorp. What are you up to?
Simplify, simplify
Jackson: We are all about delivering developer tooling to enable modern applications. We have products like Nomad, which is a scheduler; Terraform, for infrastructure-as-code; Consul, which you can use for key value configurations and service discovery; Packer for creating gold master images; and Vault, which is becoming very popular for managing “secrets” and things like that.
We are putting together a suite of products that can make integration super-easy, but they actually work well standalone, too. You could just run Terraform if you want to, or maybe you are just going to use Nomad and Consul, or maybe Consul and Vault. But the aim is that we want to simplify a lot of the problems that people have when they start building highly available, highly distributed and scalable infrastructures.
Gardner: Reynold, tell us about DigitalOcean, and why you are interested in supporting organizations like StackPointCloud and HashiCorp as they better provide services and value to their customers.
Harbin: DigitalOcean is a very intuitive cloud services platform on which to run applications. We are designed to help developers and businesses build their applications, deploy them, and scale them faster, more efficiently, and more cost effectively. Our products basically are cloud services with various configurations to maximize CPU or memory available in our data centers around the world.
We also have storage, including object storage, for a unlimited scale; or block storage that you can attach a volume of any size to, depending on your needs. And then we also include networking services for securing and scaling -- from firewalling to load balancing your applications.
All of these products are designed to be controlled, either through a simplified UI or through a very simple API, a RESTful API, so that tools like Terraform or Kubernetes orchestration through StackPointCloud can all be done through the single pane of glass of your choice. And the infrastructure that underlies it is all controlled via the API.
Users and developers want easier ways to provision and manage infrastructure.
The reason we are leaning to these kinds of partnerships and tooling is because that’s what our users want, what developers want. They want easier ways to provision and manage infrastructure. So if you want to use an orchestration tool, then we want to make that as easy and as seamless as possible.
Gardner: The infatuation with containers has moved into the full love affair level, at least based on what I see in the market. But how do we keep this from going off the rails? We have seen other cases where popularity can lead to some complexity. For example, with the way virtual machines (VMs) were adopted to a point where sprawl became such an issue.
What are the challenges we are facing, and how can organizations better prepare themselves for a world of far more containers, and perhaps a world of more serverless?
Container complexity
Baldwin: Containers are going to introduce a lot of complexity. I will just dig into one level of complexity, which is security. How to protect one host talking to another host? You need to figure out how to protect one service talking to another service. How do you secure that, how do you incur that traffic, how do you ensure that identity is handled?
When you begin looking at other pieces of the puzzle, things like ServiceMesh. We look at things like Kubernetes and Istio as complementary because you are going to need to be able to observe all of these environments. You are going to have to do all the things that you would have done with VMs, but there’s just an abundance of these things. That’s kind of what we are seeing, and that’s the level of complexity.
The tooling is still trying to catch up, and a lot of the open source tools are still in development, with some of the components still in alpha. There is a lot of need for ease-of-use around these tools, a lot of need for better user interfaces. We are at the beginning where, yes, we are trying to handle containers, and lots of containers all over the place, and trying to figure out how these things are talking to each other, and being able to just troubleshoot that.
How do you trace when your application starts to have an issue? How do you figure out where in that environment the issue is showing up? You start to learn how to you use tools like the Zipkin or you introduce OpenTracing into your stack, things like that.
Introducing
Cloud Object Storage
Gardner: Matt, what would you encourage people to do now, experiment with more tools, acquaint themselves with those tools, make demands on tools, how to head this off this from a user perspective?
Tiptoe through the technology
Baldwin: I would begin by stepping into the water, going into the shallow end of the pool by just starting to explore the technology.
I have seen organizations jump into these technologies. Take Kubernetes as an example. I have seen organizations adopt Kubernetes really early, and then they started to build their own Platform as a Service (PaaS) on top of it without actually being involved in the project and being aware of what’s happening in the project.
So there is the danger of duplicating things that are happening in the roadmap, duplicating something that’s in the roadmap that will be done in six months in the project. And now you are stuck on Kubernetes version 1.2, and how do you move to the next version of Kubernetes?
So I think there is a danger there with too early of an adoption, if you start to build too much. But at the same time there is a need to conduct proof of concepts (POCs), to start to shift some of your smaller services into new areas.
I think you need to introduce Istio into test environments and start to look at what that does for you, and start looking at all the use cases around it, things like traffic shifting. There are issues like how to do a A-B deployments, service meshes can actually give you that and start to play with that and start to plan for the future, but maybe not completely start to customize whatever you just built, because there is always a threat that the project isn’t fully baked yet.
Gardner: Sounds like it might be time to be thinking strategically, as well as tactically in how you approach these things. Maybe even get some enterprise architects involved so that you don’t get too bogged down before the standards are cooked.
Nic, what do you see as the challenges with bringing containers to use in a multi-cloud environment? What should people be thinking about to hedge against those challenges?
Sensible speed
Jackson: Look at just how fast things have moved. I mean, Kubernetes as a product practically didn’t exist two years ago. Nomad didn’t really exist two years ago. I think it was only just launched at HashiCorp in 2015. And those products are still evolving.
And I think it was a really good comment that you have to be careful about building on top of these things, and then stray too far away from the stable branch. You could end up in a situation where you can’t follow an upgrade path -- because one thing that’s for certain, the speed of evolution isn’t going to slow down.
Always try to keep abreast of where the technology is, and always make sure you have a great path. You can do that through being sensible about abstraction. In the same way that you would not necessarily depend on a concrete implementation in your code, you would depend on interfaces. You have to take a similar approach to your infrastructure, so we should be looking at depending upon interfaces, so that if a new component comes along -- something that’s better than Kubernetes – you can actually hot-swap them out without having to go through years of re-platforming.
Look at just how fast things have moved. I mean, Kubernetes as a product practically didn’t exist two years ago. Nomad didn’t really exist two years ago. I think it was only just launched at HashiCorp in 2015. And those products are still evolving.
Always try to keep abreast of where the technology is, and always make sure you have a great path. You can do that through being sensible about abstraction. In the same way that you would not necessarily depend on a concrete implementation in your code, you would depend on interfaces. You have to take a similar approach to your infrastructure, so we should be looking at depending upon interfaces, so that if a new component comes along -- something that’s better than Kubernetes – you can actually hot-swap them out without having to go through years of re-platforming.
Gardner: Reynold, how do you see solving complexity in the evolution of these technologies, and ways that early-adopters can resist getting bogged down as they continue to mature?
Harbin: The two main points that Matt and Nic have brought up are really good ones. Certainly visibility and security of these applications and these environments is really important from a functionality perspective.
As Nic mentioned, the pace at which new technologies are being developed is intense. You have to have an environment where you can test out these various tools, see what works for you, do it in a way that you can get these ideas and run them and test them and see how this technology can help your particular business. And a lot of this infrastructure in many ways is almost disposable, because you can spin it up as you need to, test it and then spin it down -- and it might only need to live for an hour or for a couple of days.
Being aware of the tools, what’s happening in terms of new functionality, and then being able to test that either locally or in a cloud environment is really going to be important.
Gardner: I was expecting at least one of you to bring up DevOps. That thinking about development in conjunction with production, and making this more of a seamless process would help. Am I off base? Matt, should DevOps be part of this solution set?
Shared language
Baldwin: Yes, it should be part of it. I guess my personal opinion on DevOps is that we are moving more toward where Ops needs to become more and more invisible. It’s more about shipping, and it’s more about focusing on the apps versus the infrastructure. And so I just see more like the capital O going to lowercase o.
What I do think is interesting right now is that developers and operators are now speaking the same language. If you are looking at Kubernetes, developers and operators are now speaking the same language. They are speaking in Kubernetes, and so that’s a very big deal. So now the developer is building it in the same way that the operator is going to understand it. The operator is going to understand how the microservice is built; the developer is going to understand how it’s built. They are all going to understand everything.
And then with multi-cloud, you could also do things like have your staging environment in one cloud and you promote your code so that your operators are running the code over in production on another provider and you could promote that code across the network, so you can do things like that, too.
They are speaking in Kubernetes, and so that’s a very big deal. So now the developer is building it in the same way that the operator is going to understand it.
I think there is some of the traditional DevOps tooling, things like Chef, things like Puppet, I don’t think have as much of a future as they used to have, because they did a lot of app management on the hosts and now that the apps are not living on the host anymore, there is not a lot for those tools to do. So just build out a host at Amazon AWS and then just deploy Kubernetes and then just let Kubernetes take over from there.
Some of those tools, their importance will lessen, like you won’t have to know Puppet as much; you likely won’t ever need to know Puppet.
Gardner: Nic, are you in the same camp, more Dev, less Ops, lowercase o?
More Dev, less Ops?
Jackson: I think it depends on two things. The first thing is the scale of your organization. When you look at a lot of tools, and you look at a lot of information that’s out there, it makes an assumption that everybody is operating at fixed scale, and I don’t think that’s the case. Pretty much any business that’s operating in a digital world, which is pretty much any business these days, you can take advantage of modern development techniques. When you start depending on the scale, then it also shifts who is potentially going to be doing the infrastructure side of things.
Smaller companies, I think you are going to get more Dev than you will Ops because that may not be a scale that can support a dedicated operations team. But larger enterprise organizations, you may have more of a platform team, more of an operations person who is using code to manage infrastructure.
Introducing
Cloud Object Storage
In either case, there’s a requirement that developers have to have an appreciation and an understanding of the platform to which they are deploying their code. They need to have that because they need to have an understanding of how things like service discovery works. How are the volumes working for persistent storage, how are things going to work in terms of scale and scalability? So if you are going to be load testing it, what are sort of the operational thresholds in terms of I/O for CPU or disk, and things like that?
I think DevOps is a really powerful concept. I certainly love working in a world where I can interact and work with the operations and the infrastructure teams. I benefit as a software engineer, and I think the infrastructure engineers benefit because those sorts of skills that we both have, we can share. So I really hope DevOps doesn’t go away, but I think the level at which that interaction occurs does very much depend on scale of your organization.
Shop around
Gardner: Are there examples of some organizations, large or small, that have embraced containers, have multi-cloud in their sights, are maybe thinking about serverless?
Baldwin: I have an example. This customer was a full-on Amazon shop, and they had not migrated to microservices. Their first step was to move to Docker, and then we moved them up to Kubernetes. These guys were an adtech firm and they had, as you can imagine, ingress traffic that had a high charge to it, and that was billed by Amazon.
So they spent a lot of time negotiating a better cloud price-point with Google. What they were able to do is stand up a Kubernetes cluster on Google Cloud and then shift the workload that was needed at that better price-point. At the same time, they kept the rest of the workload at Amazon because they were still relying on some of the other underlining services of Amazon, things like Amazon Relational Database Service (Amazon RDS).
So they didn’t want to completely move to Google, but they wanted to move something that they were taking a really large hit on, on cost, and move that to Google. So I think you are going to see multi-cloud first get used as a vendor tactic against the cloud providers to try and negotiate a better price point. So if you are doing adtech, now you are in a position where you can actually negotiate with Amazon, Google or whomever, and get a better price and just move your workload to whomever gives it to you.
So that makes it a lot more competitive. That was an early example, one of the earlier federation examples we have.
Gardner: The economic paybacks from that could be very significant, if you can leverage better deals from your cloud providers. That could be a very significant portion of your overall expenses.
Baldwin: It’s giving the power back to the consumer. We basically have a cloud monopoly, and then smaller ones. So we have Amazon AWS, and so how do you work against Amazon to reduce the price points, how do you try to break that?
And once you start to get power back to the consumer, that starts to weaken the hold on the end-user.
Gardner: Nic, an example that we can look to perhaps in a different way, one that provides a business advantage?
Go public
Jackson: One of the things that we see for a lot of enterprise customers is the cloud adoption phase. So I can’t give you the exact numbers, but the total market in terms of compute for the big four cloud providers is about 30 percent. There is something like 60 percent to 70 percent of all of the existing compute still running in private data centers. A lot of organizations are looking at moving that forward. They want to be able to adopt cloud, for whatever reason. They want better tooling to be able to do that.
You can create a federated Kubernetes cluster, or a federated Nomad cluster, and you can begin shifting your workload away from the private data center and into the cloud. You can gain that clear migration path. It allows you to run both of those platforms side by side, the distinct platform that the organization understands but also the modern platform that requires learning in terms of tooling and behavior.
That’s going to be a typical approach for a lot of the large enterprises. We are going to see a lot of the shift from private data centers into public clouds. A lot of the cloud providers are offering pretty attractive reasons in terms of licensing to do that rather than renew your license for your physical infrastructure. Why don’t you just move it off into your cloud provider?
That’s going to be a typical approach for a lot of the large enterprises. We are going to see a lot of the shift from private data centers into public clouds.
But if you’re running tens of billions of dollars worth of business, then any downtime is incredibly expensive. So you will want to ensure that you have the maximum high availability.
Baldwin: You can see that Microsoft is converting a lot of their enterprise agreements to move people over to Azure.
Jackson: Well, it’s not just Microsoft. I mean, Dell/EMC is one of the most aggressive. I could imagine a great sales strategy for them is to say, “Well, hey, rather than buying a new Dell server, why don’t you just lease one of these servers in the Dell cloud and we will manage it for you.” And you basically you’re just shifting from a capital expenditure (CapEx) to an operational expenditure (OpEx) model.
I think Oracle has a similar strategy, the Oracle cloud is up and coming. So the potential is rather than paying for an Oracle database license you could just move that database into the Oracle cloud and save yourself a lot of trouble around the maintenance of the physical data center.
Gardner: Reynold, any thoughts on examples of how orchestration of containers may be moving more toward Serverless models that have great benefits for your end users? As a public cloud, where do you see a good example of how this all works to everyone’s advantage?
No more either/or
Harbin: As developers move toward containers and orchestration, they can begin looking at cloud providers not as a choice of either/or but as, “I get to use all of them, and I get to use the products and services that are best for my particular application.”
An example of that would be a customer who was hosting their application and their storage on Amazon AWS, and a month ago DigitalOcean released our new object storage product called Spaces. Essentially they gained all the benefits of the AWS S3 object storage, but the cost is 10 times lower, at least for bandwidth.
If this particular customer could containerize their application, which basically publishes and posts content to object storage and delivers a lot of that to end users, they would have the flexibility to take advantage of new products like Spaces that are being rolled out all the time by various cloud providers. In this case, they could have easily moved their application to DigitalOcean, take advantage of our new object storage product, and essentially lowered the total cost.
But it’s not just DigitalOcean products. New technologies that can make your applications better are being released all the time, as open source projects and commercial products. Companies will gain agility if their applications are containerized, as they will be able to use new technologies much more easily.
Baldwin: There are some great abstraction layers -- things like Minio that you don’t necessarily need to interact with the underlying object storage. You have a layer that allows you to be ignorant of that, and such de-coupling is super-useful.
Companies will gain agility if their applications are containerized, as they will be able to use new technologies much more easily.
Gardner: I’m afraid we are about out of time, but I wanted to give each of you an opportunity to tell us how to learn more about your organization.
Matt Baldwin, how could people follow you and also learn more about StackPointCloud?
Baldwin: If you wanted to give Kubernetes a shot, we provide a turnkey marketplace and management platform. So you just hit the site, log in with social credentials like GitHub, and then you can start to build clusters. You can check it out via our blog on Stackpoint.io. We also run all of the major markets for the Kubernetes community, up and down the West and East Coasts.
So you can engage with us at any of the Kubernetes events in Seattle, San Francisco, New York, and wherever. Yeah, also just drop any Kubernetes slack channel and just ping us, ping me on baldwinmathew, also @baldwinmathew on Twitter.
Gardner: Nic, same thing, how can people follow you and learn more about HashiCorp?
Jackson: HashiCorp.com is a great landing site because you can bounce out to the various product sites from there. We also have a blog, which we are pretty active with. We are generally publishing at least a couple of pieces of information ourselves on there every week but we are also syndicating other stuff that we find, not necessarily always related to HashiCorp but just interesting technology things.
So you can get access to the blog through there and on Twitter following HashiCorp, myself, I am @sheriffjackson, so you can follow me on Twitter, I try to share stuff that I find interesting.
Gardner: And Reynold, learning more about DigitalOcean as well as following you or other evangelists that you think are worthy?
Harbin: The community site on DigitalOcean has 1,700 really well-curated articles. So do.co/community would be a good start, and we have several really technology-agnostic articles about containerization, as well as specific technologies like Kubernetes. They are articles, they are well written and they will teach you just how you can get started.
And then of course, the DigitalOcean website is a good resource just for our own product.
Gardner: I’m afraid we’ll have to leave it there. You’ve been listening to a sponsored BriefingsDirect discussion on container orchestration and automation solutions as a means to encourage broader adoption of containers and multi-cloud use.
We’ve learned about new ways to gain container control, we’ve also heard about serverless and discussed some of the models around DevOps in order to grease the skids toward more competitive cloud deployments and development.
So thanks to our guests, Matt Baldwin, Founder and CEO of StackPointCloud,
Nic Jackson, Developer Advocate at HashiCorp, and Reynold Harbin, Director of Product Marketing at DigitalOcean.
I’m Dana Gardner, Principal Analyst at Interarbor Solutions, your host and moderator for this ongoing series of BriefingsDirect discussions. A big thank you to our sponsor DigitalOcean for supporting these presentations.
Follow me on Twitter @Dana_Gardner and find more podcasts at BriefingsDirect.com. Thanks again for joining! Please pass this content along your IT community and do come back next time.
Listen to the podcast. Find it on iTunes. Get the mobile app. Download the transcript. Sponsor: DigitalOcean.
Transcript of a discussion on new ways to gain container orchestration, use Serverless models, and employ inclusive management to keep the container love alive and well. Copyright Interarbor Solutions, LLC, 2005-2018. All rights reserved.
You may also be interested in:
- As enterprises face mounting hybrid IT complexity, new management solutions beckon
- How mounting complexity, multi-cloud sprawl, and need for maturity hinder hybrid IT's ability to grow and thrive
- Get ready for the Post-Cloud World
- Inside story on HPC’s AI role in Bridges 'strategic reasoning' research at CMU
- Philips teams with HPE on ecosystem approach to improve healthcare informatics-driven outcome
- Inside story: How Ormuco abstracts the concepts of private and public cloud across the globe
- How Nokia refactors the video delivery business with new time-managed IT financing models
- IoT capabilities open new doors for Miami telecoms platform provider Identidad IoT
- Inside story on developing the ultimate SDN-enabled hybrid cloud object storage environment
- How IoT and OT collaborate to usher in the data-driven factory of the future
