Docker Containerization

Many of us in enterprise IT hear about new technologies like Docker containerization and Kubernetes and think, “I could figure that out if I had time, but right now I’m too busy fighting fires and figuring out other stuff that’s more important.”

That’s been my initial experience with Docker and Docker Swarm for containerization technology. In order to understand Docker, a ship metaphor, portrayed in Docker’s logo, implies that the underlying operating system is the ship with all of the shipping containers as Docker containers. This is in contrast to a VM that has “cargo or apps” that have to stay with the operating system or specific ship “moving” along. It might be a bit of a stretch, but it helped me understand the basic concepts.

For Docker Swarm, I think of a “swarm of bees” roaming in concert with each other. Containers are orchestrated by the properties defined in a Docker Swarm—meanwhile, the queen bee is in the background managing the swarm. I describe this in more detail in my LinkedIn post, Who’s Swarming Now With Docker.

Kubernetes Orchestration

Many enterprise solution architects and developers are now using Kubernetes for orchestrating Docker containers. With this technology, at first I thought, “What the heck does Kubernetes have to do with these shipping or bee metaphors for IT orchestration?” Well, it turns out that Kubernetes is Greek for “helmsman” – and thus describes who is steering the ship. I’m thinking that Kubernetes conveniently claims a better metaphor. Think about it. A Docker swarm literally means a bunch of flying insects? You be the judge.

Kubernetes is emerging as the preferred enterprise orchestration tool for containerization because it tends to be more scalable by most standards… but let’s not play favorites. Here’s an unbiased rundown that compares Kubernetes vs Docker Swarm.

The key point is to make sure that you’re using technology that provides more business value for your overall digital business objective.

Kubernetes orchestration scales to meet the needs of fast-moving digital business objectives with an open source platform that allows developers and architects to modularize services that are resilient for large enterprises. Kubernetes also has the ability to orchestrate microservice communication with load balancing and networking that is easy and scalable to almost any environment.

CloudBolt and Kubernetes

CloudBolt supports Kubernetes orchestration for enterprises in the following ways:

For more information, check out our Resource Center or download our Product Overview

Join the CloudBolt Users Slack Workspace for real-time collaboration

Ever have that moment when you just wanted to know something fast… and you didn’t feel like submitting a question to an email alias or tech community and wait?

Well, it’s time to Slack! Customers can join the CloudBolt Users Slack Workspace to ask questions, share insights, and get to know each other in this online forum. Of course, CloudBolt support is always available to help, should you wish to enter a support ticket.

“We decided to leverage a Slack Workspace and give our customers a real-time forum to share best practices and collaborate, and find ways to automate challenging tasks using CloudBolt.”
– Bernard Sanders, CTO CloudBolt Software

How do I join the CloudBolt Users Slack Workspace?

All CloudBolt customers are eligible to join. Send an email request to slack@cbgcdev.wpengine.com and ask to join the CloudBolt Users Slack Workspace. You will receive a reply within one business day with further instructions.

Then what?

We’re excited to see the innovations this CloudBolt Users Slack Workspace will catalyze as our valued customers connect and share their ideas with each other.

Note—The CloudBolt Users Slack Workspace is not an alternative to CloudBolt Support. If you encounter an issue with CloudBolt, please submit a Support ticket and our experts will be happy to help you!

Not a customer (yet)?

Learn more about CloudBolt:

Our CloudBolt hybrid cloud management platform for enterprises helps IT admins provide simple to very complex IT resources to end users from a single console.

Balancing the risk and reward for delegating tasks has always been an issue for management or leadership positions within an organization. The goal of delegating is to make an organization work more efficiently. That’s the reward. But the risk is that stuff might not get done properly or it ends up being inefficient or unexpectedly costly for one reason or another. A lack of oversight or shortage of the right skill sets can quickly turn into a disaster.

The same is true for IT provisioning and self-service.

For IT services, there have been several ways to provision resources or “delegate” them as needed over the years. The degree to which it is “self” vs “someone-else” doing it as a service has varied and continues to evolve.

As a tech marketing engineer, getting my infrastructure resources for demo environments has ranged from requesting resources in an email to IT services, to accessing everything from a public cloud provider on my own.

For example, in my first technical role, I would have multiple remote desktop sessions running on my local machine from images requested from IT. My server images were for Windows 2008 Server (W2K8 R2 to be a little nostalgic), and I would install our enterprise software solution on top of them based on build candidates. Later, I had my own login credentials to a VMware vSphere client that let me spin up my own virtual machines (VMs) with server environments from multiple operating systems—specifying the compute capacity myself. I would take snapshots of incremental versions of working VMs and roll back to older versions if something went wrong.

Eventually, I was “self-provisioning” my environment running EC2 instances on Amazon Web Services (AWS) and paying for them with a corporate credit card. I logged in to the AWS portal with my personal login credentials and everything was paid for by the company. We had a marketing budget of about $1200 per month that I used our corporate American Express card for, only to be consolidated later by central IT to make the process more efficient.

On another occasion, I had to start an instance of a Linux Ubuntu server based on a repository of open source files from Github that I accessed myself. It should be interesting to see what happens as Microsoft is buying Github and is willing to pay 7.5 billion.

With any one of these scenarios, there was a self-service element to the task, and in some cases a specific login to an environment, where I could specify settings and then start running whatever it was that I needed. If all of this ran smoothly, there was nothing to worry about. “Self-service” was a good thing.

But now considering enterprise IT, to what extent do IT leaders want to provide self-service provisioning for employees to do digital business?

Today there is a lot more at stake, and it has become a balancing act of risk and reward based on timing, technology, security, cost, and possibly a whole lot more depending on what is being self-serviced. Whether or not my tech marketing IT provisioning scenarios went well or not was practically inconsequential, because it was just me and a few others that were impacted by the efficiency of my process.

Suppose there’s a much larger scale of several thousand employees or more, maybe even 10,000 employees at some point. A self-service strategy to have the right IT enterprise resources at the right time for the right digital task can have a huge impact on the overall success of the digital business underway.

Here are some ways that IT leaders enable a continuum of self-service IT:

CloudBolt is a cloud management platform for all clouds – internal and external – helping end users leverage compute, network, and storage resources from anywhere that is deemed appropriate for the enterprise. Enterprises can deploy infrastructure to run digital business services and applications when and where they need them across multiple private cloud and public resources to avoid vendor lock-in.

Cloud Anxiety to Confidence

A few years ago, many of us snickered about IT initiatives and going to “The Cloud.” There was something catchy and mysterious about it—even over-pronouncing it like, “We’re moving to the Clooooo a dah.” My IT friends are probably now smirking when they see I’m at CloudBolt.

Cloud anything was being hyped everywhere and is still going strong. Anyone remember going from Microsoft Word and PowerPoint installed locally to Office 365? That was about five or six years ago to put cloud strategy adoption in perspective.

Initially, enterprises felt uncomfortable “moving to the cloud.” Some still do. There’s a lot of uncertainty about cost, performance, integration, control, and security. I remember attending Microsoft Ignite last year and hearing a few stories about some larger organizations who let their developers move to the cloud and ended up moving stuff back on premises, or others that got in deep trouble for spending too much. They had to reign the initiatives in and reconsider their approach.

For more fortunate enterprises, effective cloud adoption strategies have helped them disrupt almost every market—how we book travel, get around with rideshare, order food online, or even process home mortgages. It still amazes me that I can take a picture of a check and get it deposited in my account so quickly. The reality is that these enhanced customer experiences exist because a well thought out hybrid cloud strategy has most likely been put in place to run parts of the overall end-to-end delivery of these applications.

The mandate to move to the cloud is a top-down initiative that many IT leaders face while the “what, where, and why” is rapidly changing. Multiple vendors competing to offer cloud services as well as new technologies like containerization make it hard to keep up.

Hybrid Cloud and Multi-Cloud Strategies

Here are three important answers to questions related to enterprise hybrid cloud and multi-cloud cloud strategies to help alleviate any anxiety—even the snickering that some of us still do.  

1) How do you explain cloud computing and what hybrid cloud, multi-cloud, and private cloud and public cloud mean?

Cloud computing is simply running digital assets in an environment that is not hosted by infrastructure local to the users of the assets. Think of it as anything that runs somewhere else but you can access it typically by a network connection to a private or public network. We log on to our email accounts that are managed somewhere in “the cloud,” as opposed to legacy email servers hosted by local IT administrators. Someone in IT could physically show you those corporate email servers in some “on-premises” server room closet. Shhhhh, some folks are still doing it that way. The disruptors are not.

Hybrid cloud is typically referred to as a platform where your strategy is to run digital assets from a combination of on-premises infrastructure and some assets from public or private cloud environments. A common hybrid cloud deployment is to have application servers and web servers that are load balanced and running in the cloud, while the backend databases are hosted on premises for the specific applications or services running in the cloud.

To be even more specific, solution architects consider that a hybrid cloud platform is orchestrated to use certain resources from the cloud vs. on-premises elements based on conditions. For example, when demand increases, some of the computing resources could be dynamically provisioned to the cloud to handle the spike. Having this visibility and control is what some enterprises consider the holy grail—right-fitting all the resources at the right time for the right usage demands and not sacrifice performance or overspend.

Public clouds and private clouds are just as implied. Public cloud resources are available through the public internet and often include proprietary solutions that are marketed and sold by vendors to scale with your demand, while private clouds are only accessed by a private network that no unauthorized users can access or use.

Multi-cloud is a combination of everything. You could say that a multi-cloud strategy considers a range of options from cloud providers to develop a hybrid cloud platform. You could switch from one public or private cloud environment to another for a hybrid cloud strategy. Having a mix of enterprise Software-as-a-Service (SaaS) applications that run key elements of the enterprise such as sales, marketing, customer support, and HR functions is considered a multi-cloud strategy.

2) How do enterprises consider costs associated with hybrid cloud and multi-cloud strategies?

Enterprises typically consider their cloud assets as part of the operating expense (OpEx) for doing business and can fluctuate from month-to-month based on usage.

On-premises infrastructure assets are part of the capital expenditure (CapEx) for an organization and are part of a budget on a yearly basis.

When doing business, you might think that the on-premises portion of costs as spending a lot of money at first to get started. Once you’re up and running, you don’t have to pay that much. It’s like having your own bike vs. renting one on a daily basis. You typically have to pay several hundred dollars to buy a bike (CapEx). Once that’s done, you can ride your bike any day without paying anything. On the other hand, instead of paying that money up front, you can just pay a little each day to ride a rented bike and only use it when you need it (OpEx). When you’re not using it, you don’t have to worry about storing it.

Specifically for business functions run by SaaS applications and their costs, enterprises will compare costs among cloud providers to choose a provider and weigh the cost of owning the infrastructure that is running on premises vs. that which can be “rented’ by a public or private cloud provider.  

Where it gets a bit complex—but worth considering for enterprise cloud adoption—is optimizing a hybrid cloud environment so that the cost of infrastructure is more closely aligned with usage and benefit.

Sometimes it’s worth it to pay for on-demand resources from a cloud provider that are only used when needed—you don’t lose business by paying the premium. In the meantime, you’re not overspending on the idle resources that could be running without the demand.

This hybrid cloud optimization from properly orchestrated resource can be the differentiator that separates who is successful and who is not.

3) What about the performance, security, and control for hybrid cloud and multi-cloud strategies?

Enterprises know that if they want complete control and security of their digital assets, then adopting a cloud strategy is not the way to go. Several years ago, governments and most large enterprises would not even consider cloud strategies primarily because of the loss of control. They also wanted to closely monitor the performance based on their own service level agreements (SLAs).

That is changing. There are now Department of Defense (DoD) cloud resources available on AWS, Azure, and Google Cloud. These vendors all claim that because of automation and auditing processes available in these environments, compliance and security might even be more “hardened” in their hosted environments.

Some SaaS providers will provide an SLA agreement for their enterprise customers, similar to what the enterprise would have for the IT services hosted in house. These SLA agreements can guarantee uptime, availability, data rates, and anything measurable. Some IT departments use that criteria for selecting a SaaS vendor to use instead of a solution they used to have more control over in the past.

We’ve learned a lot about clouds along the way and it’s only going to keep changing. The competition for offering technology and solutions in the cloud is just ramping up for massive adoption from enterprises. Digital transformation initiatives from these enterprises that boost the most effective use of The Cloud will continue to be the factor that separates whether companies thrive or die.