Understanding and implementing repeatable patterns effectively is what adds value to any operation, whether it’s making a pizza, conducting a symphony, or building applications at scale using a hybrid, multi-cloud modular approach.

Watching a pizza made in a fast-paced delivery shop is a real testament to having sets of ready-made components available to make and deliver at scale. Dough, cheese, tomato sauce, meats, vegetables, and other toppings need to be assembled and shoved in the oven without delay. This makes all the difference in delivering a pizza within the popular time frame of 30 minutes or less. A conductor of a symphony, in a slightly different scenario, has access to modular components that make up the desired sound from brass, string, woodwind, percussion, and even vocal instruments. He or she relies on the readiness of the musicians and their instruments in a modular way.   

The ability to duplicate these approaches of modularity plays a huge role in delivering an optimal hybrid and multi-cloud strategy to help developers get the resources they need to deliver digital value to the market with the required components at scale. As complexity increases, the need for modularity also increases. Having these ready-made sets of resources to deliver hundreds of made-to-order items will not be the same as delivering only plain cheese pizzas, a single score of music, or simple sets of VMs to internal users of an organization.

When it comes to delivering a complex set of resources with requirements for configuration, security, and cost controls, a modular approach will have a huge impact on a successful outcome. It’s very inefficient if, after a pizza delivery, you had to add all the special ingredients. Likewise, with an application stack that includes VMs, you wouldn’t want to have to add all the configuration settings, patches from an OS update, or any other item that would be better delivered at the time of provisioning and orchestrating the resources.

Integrating the Process of Modular Design

When it comes to provisioning infrastructure resources in modern enterprises, the complexity compared to making a pizza will only go so far but illustrates the need for modularity. Each set of resources required by developers and DevOps teams will vary depending on the operating systems, the location of the virtual machines, the number and size of the virtual machines, as well as all the ingredients that are more abstract—like connecting the hosts to a network or adding them to a domain.

Consider these key aspects of a good modular approach:

Resource Connections

Resource connections are configured integrations with the target environments. Instead of having to log in and provision resources in each separate environment, you can go to one location and have a ready-made connection to the environment that has the required features you want configured ahead of time. Most cloud management platforms, like CloudBolt, have these ready-made connections. Each cloud management provider will have varying depths of coverage with each of the target resources.  

Environments

Once you’ve connected to a specific cloud resource, another level of modularity is the ability to create specific environments that you know are the most common and have the specific setting for that environment already set up. For example, you could create specific environments that do not have public IP addresses available to configure for some of the users in your environment. This provides a level of security from accidentally making an environment subject to malicious attacks.

Configurations

It’s very common for enterprise level provisioning to use one of the popular configuration management tools such as Chef, Puppet, Ansible, or Saltstack. Having these tools integrated as modular connections to your resource provisioning will make the process go smoother. These sets of tasks can be grouped and called for whatever application stack is needed for a set of internal users like developers or DevOps engineers.

User Access

Managing users in an enterprise environment is no simple task. Within the organization, there is usually an Active Directory service or LDAP system that is used to manage user access to many of the enterprise tools used by most organizations. Connecting to those environments is a good way to re-use existing user permissions. Taking it one step further, when provisioning, these user profiles can be the basis for the modular groups to manage in a cloud provisioning process. Similar to restricting the ability to not expose public IPs in some environments, sets of users could require an approval process to provision resources.

CloudBolt Can Help

CloudBolt provides one place for all of these modularization strategies to be implemented. In addition, CloudBolt provides an extensible plugin in architecture that helps you modularize any provisioning activity you require. Once you identify a set of repeatable steps, you can create a plugin that executes them.

Ready to see it for yourself? Request a demo!

After attending DevOpsDays in Baltimore this past week, I was convinced that the push to cloud-native could not be more resonate. The fear of lock-in and having less control over performance and security has turned upside down. One firm, Fearless—a name that speaks for itself—were sponsors of the event and had many volunteers who contributed to its success. They weren’t afraid of much of anything, wearing silly hats with a super casual style to make the whole event fun along with planned topics, open sessions, and lightning rounds for folks to engage.

For specific cloud-native examples, friends close to us in Washington, DC at DHS provided details of their move to the cloud for the processing of citizenship. PayPal attendees from North Baltimore gave us the rundown for their security payments group to our team of CloudBolt experts, Alan, Jasmine, Lauren, and Sam. These larger organizations, as well as many other smaller teams at the conference, discussed how a cloud-native approach is working for them. Performance and security were not holding them back.

In all cases, the representatives of these efforts described the DevOps culture change that they underwent and how they are now convincing other teams within their organizations to make the shift. It was all very convincing to me, as we at CloudBolt are moving toward deeper partnerships with AWS, Google, and MS Azure. In response to this shift in focus, we’re also strengthening the cloud-native offerings for our prospects and customers.

Why Cloud-Native?

The ability to develop, test, and deploy application architectures from one public provider that scale on demand and take advantage of tightly-coupled, pay-as-you-go services is the future of digital services and what’s considered a cloud-native approach. Using scripts, either in-house or by using Terraform, DevOps teams manage versions of infrastructure as code IaC that connect to provider resources, typically stored in Github. This helps DevOps teams quickly transition from one development state to the next along with the ability to roll back or roll forward from a state that is not successful. According to the DevOps engineers who spoke at the conference and participated in the open sessions, code-based deployments are much easier to manage than using the GUI of their cloud providers.  

The shift to this approach is now what differentiates one company from another, or keeps one team within an organization from “…not being on the front page of the Washington Post” as one of the DevOps speakers for DHS put it.

So, let’s consider what can go wrong and what to do to make the process go smoother. The goal is for enterprise DevOps teams to get the most out of cloud-native application architectures and the value of their subscriptions.

Getting to Zen

As with any initiative, unlimited infrastructure resources for everyone and the ability to have stuff ready to go at a moments notice will make the lives of most DevOps engineers super happy. That is, of course, until someone gets hurt. In this case, the hurt will be the sticker-shock of an unexpected cloud provider bill. In another case, it could be the person or team who has responsibility for the scripting framework, as well as whatever model they’re using for delivering infrastructure, leaving the company while leaving very little documentation. Here are three ways CloudBolt can help:

Resource Management / Self-Service

Connections to public cloud providers from every operator to a specific cloud can lead to inefficiencies. A loosely managed scripting environment will be prone to one-offs that could lead to disasters in troubleshooting. Terraform scripts can access the CloudBolt API and execute any blueprint orchestrated to provision resources through any of its resource handlers. CloudBolt as a self-service portal can also be the starting point of any Terraform script. Having the connections to providers managed in a single platform can make it easier for IT admins and developers will not need to manage this part of the backend complexity.

Cost Control

Although cost control is part of a public cloud provider’s promise, it has not always been true, and probably won’t be first on their list to help enterprise, cloud-native projects. The more you spend, the more they make in profit. At some point, competition will weed out the grip of vendor lock-in and pricing. You can skip this altogether with cost control from a cloud management platform like CloudBolt. Synchronize inventory of Terraform-deployed infrastructure based on resource handlers in CloudBolt, then run checks on what is being utilized and who is using the infrastructure to help make better spending decisions. Even better, you can use CloudBolt blueprints as your Terraform provider and you can build in cost control, quota enforcement, and one, two, or three-tier approvals if necessary.

Extensibility

After development teams have hardened their Terraform scripts or any IT provisioning they do and their apps are in production, they typically throw them over the fence to IT operations who can then manage them and provide oversight. If anything goes wrong, it’s the fault of IT which is not good. Instead, use Terraform with CloudBolt to arm IT operations teams with more extensible infrastructure provisioning workflows that can be orchestrated at either the CloudBolt level or within Terraform from the developers. This way the responsibility is shared as was intended in the first place with DevOps.

Summary

From Zero to Zen means getting the most from cloud-native without runaway spending while having the resource handlers in place to implement a more carefully orchestrated environment that scales with your enterprise.The person or team who left the organization will not have as much of an impact if IT is informed, and using a standard convention of extensibility. The unexpected spending will be in check and developers will not get hit with surprise bills or the grief an IT leader in their organization.

Want to learn more? Read this free ebook!

On a typical Monday at CloudBolt we have a weekly meeting called “Chalk Talk” to discuss industry trends. Recently, Sam Collura from our Inside Sales Team asked, “When are we going to talk about Terraform?” and continued, “A lot of my prospects are asking about it, and… I think we need to be able to discuss our integration better.” Sam as many others are hearing is that Terraform has become quite popular for DevOps and developer workflows.

SEE OUR CLOUD MANAGEMENT PLATFORM IN ACTION

 

Terraform has been an important homework assignment of mine because the industry is getting more accustomed to agile workflows with code-based workflows. Sam’s question was not the first time and will not be the last time we’ll hear about it from our CloudBolt prospects.

After that Monday, I went to work and studied the engineering work from our team in Portland who, incidentally, just received the “Most Influential Technology Company in Oregon Award”. I found that we’ve been working on integrating with Terraform for quite some time to take advantage of its code-based provisioning of resources—since 2016 specifically. Although we don’t have an OOTB plugin today, our extensible framework complements Terraform a number of ways. Essentially, we can help to make IT administrators who automate with Terraform into heroes for their dev teams.

Terraform Explained

Terraform as Infrastructure-as-Code (IaC) is a great tool to get infrastructure to developers who use continuous integration/continuous delivery (CI/CD) application development workflows. The Terraform code that is used to deploy infrastructure is maintained in a GitHub repository with versioning so that incremental changes to the underlying infrastructure can be tracked and shared.

Developers who are coding applications need an environment where they can do coding with consistency, especially when multiple developers are working in environments that must be identical. Their adoption of Terraform is no coincidence, as developers and DevOps engineers have been doing a very similar version control with branches of code that they are developing to merge into the main core application. This helps to ensure that efficient and stable application code goes from development to testing and then into production without a hitch.

Over time, certain workflows using Terraform become common, so there is the ability to modularize parts of the deployment scripts to be reused for the wide range of infrastructure needs for developers. This is a great video to get familiar with how Terraform works, Provisioning VMs to Public Clouds with Terraform.

Customers can use Terraform Open Source or Terraform Enterprise from Hashicorp. The latter provides organizational features that help to manage development for enterprises.

Terraform & CloudBolt

CloudBolt works well with Terraform, especially when the scripts and development environments have matured and can be used in enterprise-wide workflows where visibility and control at scale take on more importance. CloudBolt can synchronize and manage running infrastructure from the various environments where infrastructure is deployed by Terraform. CloudBolt can also be used as the provider that Terraform calls to provision resources.

You can then configure CloudBolt and Terraform together to enforce quotas, power schedules, and expiration dates for enterprise-wide full, lifecycle management of the infrastructure. This can be enforced and reported for each business unit or group where the value of the infrastructure is tied directly to business outcomes.

Here’s a summary of key uses and benefits:

The adoption of agile frameworks for both application development and infrastructure provisioning continues to be a huge differentiator for successful enterprises. The ability to innovate faster and deliver value responsive to your market demand is the underlying objective for using the code-based infrastructure provisioning from Terraform. Having the visibility and control from a single platform using CloudBolt gives you the ability to provide faster time to value with a self-service IT portal as well as the ability to control costs and respond to any changing requirements with an easy-to-use, extensible platform.

To learn more about how CloudBolt enables self-service IT and empowers your end-users, download this free eBook!

Top-rated restaurants have cooks, servers, and patrons who each thrive by getting everything they need to create, deliver, or consume something scrumptious that has value during a specific time and date. Each role requires a different set of skills and involves doing something different as the main objective. There’s definitely some overlap, as a chef might need to taste dishes to make sure they’re just right, or patrons serve themselves from a buffet or counter line.

In a similar way for IT provisioning, distinct roles for creating, delivering, and consuming digital resources thrive in a fast-paced enterprise. It’s no coincidence that we hear terms like recipe to characterize IT provisioning as a sequence of interdependent steps. There’s even a brand called Chef for application deployment. Here’s a set of top enterprise projects to provision as part of a thriving IT restaurant or enterprise.   

Raw Ingredients/Resources for Developers

At the foundation of any digital enterprise, developers need the infrastructure to build on and deliver code at regular intervals. The code runs the digital business of the enterprise, and can be anything from programmatically displaying choices in an online eCommerce site to updating the GPS location of your rideshare driver on an interactive map. Typically, the code can be running on virtual machines (VMs) that are discrete servers with an operating system (OS) and computing power required to support the code. More modern technology includes code that runs in containers that are more modular, but still have the underlying OS that needs to be provisioned. Recently, the major public cloud providers offer “serverless” computing where developers need to only submit the code they want to run and the provider runs it, abstracting the infrastructure that runs from the end user (developer).

Test Kitchens/Support Environments

Enterprises need to have environments that they can test or troubleshoot in without introducing problems in the “real” production environment. If these test or support environments that mirror the real environment can be spun up or down on demand, the enterprise will save a lot in time and resources. By not having to start from scratch each time there’s a test or support case they save a lot of time. If the infrastructure is running in a public cloud environment, the monthly bill for these resources will be a lot less when the infrastructure is only running for the period of time required rather than on 24/7. These environments are also good to use in training classes for both internal staff and end users who might be customers using a system that is developed and sold by the enterprise.

Franchising/Expansion

A repeatable, standardized set of IT resources can be configured for automation. A new banking branch, a fast food venue, or new line of clothing can be set up and delivered as an IT bundle that interacts with all the physical and digital touch points of a business. Think of your favorite fast food chain that opens a store in a new location. When you go, you have the expectation of consistency for how you order, pick up, and pay. All of the digital processing required to do that could be a “blueprint” that is ready to go whenever the new business is opened and with all the backend servers, VMs, and connections to accounting or databases set up so that they do not have to be created from scratch every time. There are specific settings for the location of the business but the bulk of it can be already set up and available.

On-Demand Service/Big Data Processing

Providing the big data processing infrastructure with the compute power to analyze large volumes of data requires a lot of planning and capital expenditure to stand up in a traditional data center. Many enterprises have found that this is too costly to maintain, so they are turning to public cloud providers who have ready-made big data processing and the complicated Apache Spark and Hadoop clusters required to process on-demand in the cloud. Enterprises only need to run it when necessary, and there’s no need to hire a data architect or infrastructure admin to install and maintain the same IT resources required to do the equivalent processing on-premises.

CloudBolt Automation for IT Projects

Enterprise projects like these that need to be provisioned can be anything from the raw resources for developers to use to build an application stack to run in production to the big data processing projects on demand. Just like a smoothly run restaurant, the IT environment can be configured to get the digital assets to the right people at the right time to create, serve, or consume. All of it can be configured and some of the steps automated in a CloudBolt Blueprint.

Ready to see how CloudBolt can help? Request a demo!

Typically, when buying a car, there’s a sticker price that you agree to pay over time to drive it off the lot. Then there are a list of expenses required to keep the car on the road—monthly payments, licensing, maintenance, insurance, etc.

Just about any big purchase includes a lot more than just the sticker price. Smart buyers consider the price of the car along with available interest rates and terms. In some cases, a car might be priced higher but at a lower interest rate so that you could end up paying less in the long run. Insurance rates also vary depending on the type of car as well as the cost for routine maintenance that can be significantly higher for some vehicles.

All of these factors play a role in the Total Cost of Ownership (TCO) for a vehicle. Considering the price and interest rate as well as expenses can influence your decision. The TCO for any item you use regularly can have a huge impact on your life. If you buy a bigger house with more land and swimming pool, your TCO will obviously be much higher than for a more modest home. As the benefits are what you’re likely after, you might want to pay more for something realizing that the TCO is higher than another option.

Hybrid Cloud TCO

Similarly, for enterprise hybrid cloud initiatives, there’s going to be an initial cost for cloud resources and accompanying IT tools and processes based on a combination of one or more of the following: licensing fees, subscription rates, consumption rates, and metered usage.

Each cloud provider will have competitive rates to offer for various IT resources on a subscription basis, and then they’ll have costs for various enterprise IT tools associated with delivering and maintaining the consumption of these resources by end users.

For example, you might have a ticketing system like ServiceNow or Cherwell and enterprise monitoring from AppDynamics or Datadog. For backup and disaster recovery, you could be using Commvault or Veeam. There will be no shortage of complexity.

Some IT tools and Infrastructure or Software-as-a-Service (IaaS or SaaS) offerings will require customizations, training, and various levels of ongoing support. Cloud delivery and management software will be complementary and considered as part of the TCO for most enterprises. As you consider the complexity and the choices you have, consider these top-5 critical factors for TCO.

Top-5 Critical Factors for TCO

When considering any solution that becomes part of your IT resource investment in the cloud or on-premises, make sure you evaluate your choices based on a set of factors similar to the following:

  1. Implementation—This includes where and how the software solution is installed and maintained. In some cases, the architecture of the solution might require agents and services running from multiple nodes that require extra support. Take into account this more complex type of architecture compared to a lighter weight solution that might be implemented as SaaS or as an all-in-one virtual appliance.
  2. Training—The cost of training can include purchasing the training units themselves and the seat time to learn the material. Find out how the vendor suggests learning how to be proficient in using the software. Some solutions are more intuitive than others and might have enough online community support or very responsive technical support so that more formal training might be less of a need.
  3. Time to Value—This is an overlapping consideration based on the training, implementation and other factors related to the usability of the software. How long does it take to get the solution up and running? It might just be a matter of integrating secure, role-based access and the connection settings to various cloud providers and other complementary IT tools. In other cases, it could require a six-month engagement of professional services to get started. Both are equally valid depending on what you’re after for your hybrid cloud initiative.
  4. Extensibility—This includes the ability of the software to interoperate with other solutions with programmable access to other REST APIs along with any built-in support for the most common best-practice connections to cloud service providers and other IT tools. The idea is that if the solution does not automatically connect to another system, can it be easily programmed to do so? Likewise, does the solution itself have an API to be called by other systems?
  5. Upgrading—Because of the fast pace of digital innovation and new business requirements, technologies are being added and enhanced while new features are implemented everywhere in the digital ecosystem. A solution participating in this digital ecosystem must be able to keep up with changes and support any new and enhanced technologies as they emerge. Therefore, an upgrade process that occurs more frequently and is easy to achieve will contribute to a lower TCO.

Other factors to consider for TCO include the cost for Professional Services when necessary, as well as the efficiency and effectiveness of Technical Support. CloudBolt as an enterprise hybrid cloud delivery and management solution has been purpose-built to make sure that all five of these factors affecting TCO are continually being addressed and prioritized for customers without compromise.

Want to see how CloudBolt can help you? Request a demo!

There’s an incredible amount of monitoring data in enterprise IT environments from the network, the infrastructure, and the applications. Consider that monitoring everything all the time for every aspect of your running infrastructure, although potentially useful, might not be a good use of time and resources. Strategic monitoring will lead to better outcomes in most cases.

Suppose a particular set of servers has the same load applied to it day after day and never reaches any level of saturation from CPU utilization or memory usage. Why invest any special monitoring for it if the servers are not causing issues? On the other hand, in an environment where demand fluctuates and the ability to scale up with that demand using more infrastructure, it’s important to know when a certain monitored threshold is reached. This will kick in load balancing or a horizontal scale of additional servers to handle the load.

Enterprises have the ability to strategically monitor with the many tools available to them.

Strategic Monitoring

Monitoring can be focused on 1) the infrastructure that runs applications and services of any kind, 2) the application as a whole from end-to-end, or 3) any combination of the two. Each of the monitoring tools available from enterprise favorites such as AppDynamics, New Relic, and Splunk will have a range of approaches that include deep statistics into the health of any component combined with some kind of predictive analytics that help pinpoint potential issues before they become costly problems. Logging can be done for any system and can be retrieved and analyzed for troubleshooting and insights.

Other monitoring tools, like Data Dog, Nagios, and Solarwinds, provide robust infrastructure and network metrics for IT operations that have enterprise-level visibility in order to facilitate smooth troubleshooting and alerting frameworks. Public cloud providers themselves include native monitoring of the infrastructure with an API to retrieve the necessary metrics for any reporting tool that can use them. For instance, CloudWatch metrics from Amazon Web Services (AWS) can easily be retrieved via an API and used for monitoring EC2 instances.  

Strategic monitoring for hybrid cloud provisioning at the enterprise level is wide open for any IT administrator or DevOps engineer who needs to include monitoring with the provisioning process. The range of tools and the breadth of coverage is so open—any metric that you might need for the infrastructure running in production will most likely be armed with plenty of monitoring ability from one of your existing enterprise tools. There’s no need to collect it again with another tool or instrument your provisioned infrastructure with another agent at the time of provisioning unless that is part of your strategy.

Much of hybrid cloud provisioning involves setting up ready-made application stacks for developers to use as a starting point to develop the environment further with software coding along with digital business logic that they need to ultimately run in production. Monitoring might be better addressed later on in the full lifecycle of this infrastructure. In other cases, the hybrid cloud provisioning could be deploying production-ready web servers, app servers, or instances of fully developed containerization. In this case, monitoring can be included in the blueprint for whatever downstream enterprise tool will be used to track and monitor that resource. Another provisioning process might be for lab environments identical to customer or user environments where developers want to access the resources for a given amount of time and then turn them off when not in use. There might be no need for enterprise-grade monitoring in this case.

All of your hybrid cloud provisioning processes will require a strategic approach to monitoring that is gets the right, actionable monitoring data that suits the workflow.

CloudBolt provides monitoring of usage statistics to help control costs and manage infrastructure by department or group usage. When a particular user or sets of users start to consume beyond a level set by their quota, action can be taken to approve or deny more resources. You can monitor server utilization statistics from VMware Servers and AWS EC2 instances out-of-the-box and configure integration with any existing monitoring system on the network that is relevant to your strategic hybrid cloud provisioning plan.

Want to see how CloudBolt can help you? Request a demo!

“Shadow IT” no longer has the same negative connotation that it once had. For many organizations, activities that used to be hiding in the shadows are now, quite cleverly, part of the mainstream. These shadow IT activities were first perceived as “out of bounds”, but now provide significant value to the business bottom line.

A great example of this shift would be moving from on-premises file sharing in password-protected file servers to using file sharing apps like Dropbox, Google Docs, or Box. Remember when IT administrators would send out friendly reminders to purge directories from unwanted or outdated materials because they were reaching capacity? We also had to change our passwords every quarter and could not access the file share drives remotely unless we “tunneled in” through a VPN connection. These systems might still be around but many of us now use other systems.

In the spirit of productivity, a lot of us started using publicly available file sharing apps informally to avoid IT administrator controls. Before the public file sharing apps, we used to email a document to ourselves to work on at home and then upload it the next day. With free subscriptions to a certain amount of storage “in the cloud,” we found these file share apps easier to use. hey would also sync with any device we needed—including our work computers. Shhhh! Some of us thought they were so convenient that we paid a small price for them without issue. The convenience was far greater than the risk.

Some organizations, such as banks and government agencies, were not as open to this as employees were. Many IT departments in larger enterprises tried to enforce policies that banned the use of these file sharing apps as well as other Software-as-a-Service (SaaS) apps anywhere near the managed local area network (LAN). It was not only a matter of security, but also a matter of network performance. Transferring gigabytes of files across the LAN to and from the Internet to some cloud service caused network congestion in private networks that was not anticipated.

Eventually, these cloud providers offered enterprise-ready editions of their file sharing and collaboration tools and voilà—what was once shadow IT became the norm. Microsoft had an early start with their online edition of SharePoint, SharePoint was specifically designed for the enterprise at the beginning, whereas the others, not so much. First seizing on personal adoption, Dropbox, Google Docs, and Box now all have enterprise editions.

Hybrid Cloud and Shadow IT

Similarly, in a competitive enterprise environment, the race to innovate faster allures individual contributors to turn to self-service their infrastructure resources rather than going through their IT departments. Even whole business units within enterprise organizations have stopped going to central IT and prefer to align their business value directly with their budget wherever it makes sense. Public cloud providers such as Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure seized on this opportunity. Anyone or any department within an organization with a credit card can secure enterprise-grade computing power from a public cloud provider in a matter of minutes.

This speed and agility definitely facilitates architecting new and improved applications and services. Moreover, bridging the old with the new to implement a hybrid cloud strategy so that on-premises infrastructure can be integrated with new initiatives in private and public clouds makes self-service even more compelling. Why not enable the convenient, self-service aspect of public cloud provider resources across the whole enterprise? In other words, provide access to on-premises and private cloud resources just as easy to end users as the public cloud. Go to a portal, log in, and grab your stuff.

The fast pace and inevitable complexity of offering so many resources from disparate sources introduce risks that must be balanced with control or IT governance. As DevOps engineers responsible for securing application development stacks go out on their own to secure IT resources, they must be careful not to make bad decisions without the support of central IT.

When IT projects like this fail, you can bet that IT leaders will likely play the shadow IT card. But it doesn’t have to be like that in today’s enterprises. Many IT leaders have turned to centralized platforms of self-service provisioning that empower users with easy-to-get IT resources without a lot of back and forth requesting and provisioning resources between IT and business units, end users, and others. IT administrators can build in the necessary governance and control while also providing the ease of use and immediate access to public cloud and on-premises resources that end users crave.

A centralized platform can help:

A little upfront planning will help end users innovate on the edges with their hybrid cloud strategies without succumbing to the throes of shadow IT.  

CloudBold is an enterprise hybrid cloud platform with pre-built connections to the most common on-premises, private, and public cloud providers, as well as extensibility to any resources, so there’s no need to worry about the loss of control or governance as end users are empowered.

Ready to learn more? Request a demo!

Most enterprises now have a mix of cloud technologies to meet their IT needs while remaining competitive in the new age of digital transformation. They subscribe to many Software-as-a-Service (SaaS) applications supporting their business and set up IT environments in both private and public clouds to develop mission-critical applications.

They do this to achieve one or more of the following benefits:

In economics, there’s an interesting phenomenon known as the Law of Diminishing Returns. In production, when you add another resource to increase output, there is a point when that additional input will no longer provide the same expected improvement (or return) that it did in the past.

Think of it this way. Suppose you have an apple orchard and you hire workers to harvest the apples. Assume that each worker can only pick so many apples per hour. At some point, while adding more workers to do this task, eventually you will not get the same output as before because they would start getting in each other’s way.

Now let’s consider cloud computing as a potentially productive activity. The more we add cloud computing to our complex IT environment as a strategy, is there a point where we start to see diminishing returns? In other words, does cloud computing from multiple platforms thwart the incremental benefits?  Or, is it that the more you add to the cloud, the more benefits you gain indefinitely? This might be a real head scratcher depending on how you look at it.

Let’s say that by adding more cloud computing to an existing environment—all other things being equal—will yield incremental expected benefits. Given a choice to do the same computing from another provider that is cheaper or with better functionality might also give you incremental expected benefits.

During this scaling up process, it’s possible that more cloud providers and functionality is added throughout the enterprise. Some parts of this cloud could be developed in different departments where no one else in the enterprise knows about or even knows how to use. The people responsible for these IT resources can move on from the organization and these resources will go unattended.

As this cycle continues, the forces of the law of diminishing returns might be at play. The enterprise is experiencing less efficiency as cloud computing or “workers” are stumbling over each other.

One way to address this complexity is to have a central platform, where IT can connect to any 3rd-party resource, gather the inventory of cloud computing resources, and provision new resources to be used by anyone in the organization from one place. Self-service IT can be enabled when appropriate.

With this capability in place, you can:

No matter how you approach this problem, having a holistic view of your multi-cloud or hybrid cloud environment coupled with the ability to know the costs and what functions are consuming resources is going to keep you ahead of the game and less likely to experience the negative consequences of The Law of Diminishing Returns.

Kubernetes, the open source container orchestration tool, has become the defacto choice for enterprises looking to scale their applications with production-grade containerization. According to a recent Datadog survey, its adoption rate has gone up by 10% in 2018.

Kubernetes is now distributed with Docker and available on the major public cloud platforms including AWS, Azure, and GCP And if you want to tinker with the source directly you can find instruction on Github here. Kubernetes is one of the top ten repositories being used on Github today and the community is exploding.

Why Kubernetes?

Google has been using Kubernetes in production for 15 years. This time-honored proof of working in Google’s web-scale environments makes is a solid fit for enterprise adoption. Over the years it has had the care and feeding of some of the top developers at Google. Choosing to be open source was brilliant. Now adopted across competing cloud providers, Kubernetes is sometimes referred to as K8s (K with eight letters and then “s”). The open source project is now hosted by the Cloud Native Computing Foundation (CNCF) and available here. As more enterprises adopt K8s, it has become  the currency for migrating, managing, and scaling containerization across the hybrid cloud landscape.

Containers and Kubernetes

Containers can be deployed and run just about anywhere without any orchestration from Kubernetes or other orchestration tools. Containers enable developers to modularize the functionality of extremely complex application architectures as microservices with dedicated roles that support digital business for the enterprise. You can essentially start and stop containerized services independently and manually. Orchestrating them with automation requires a little more sophistication.  

Kubernetes does the orchestration and management of containers so that they can be used in a production environment with the proper set of controls. You can essentially describe the desired state of how you want the containers to run and where and what to do if something goes wrong. Kubernetes then does all the work to make sure that this desired state is always kept up and running.

Kubernetes in production includes monitoring, networking, and load balancing so that when demand increases, the application architecture developed with containers scales and meets the demand. Kubernetes also provides a way to update to container versions in a continuous delivery model and rollback to a previous state when necessary.

For a quick summary overview, check out this video.

For a more detailed rundown, go here: What is Kubernetes?

CloudBolt and Kubernetes

CloudBolt supports Kubernetes orchestration for enterprises in the following ways: