When companies began entertaining the idea of running their applications in the cloud, the immediate focus was on trying to forklift entire application suites. What most have learned is that, in reality, it was going to require a step back to re-evaluate the deployment of the entire application stack, leveraging resources from a cloud provider – similar to how those one-tap-launch mobile applications were being run on smartphones. It could be argued that the evolution of consumer tech was the biggest thing that spurred the use of the cloud in commercial IT situations.
Many departments began experimenting with moving applications to the cloud, only to see a disconnect between those applications and the on-premises infrastructure. None of their management and monitoring tools worked anymore so new tools were required. In fact, some of the tools that early adopters needed had not even been created yet, leaving CIOs shrugging their shoulders wondering what to do next.
As this demand from smartphone-trained users came more into focus and enterprises began to get their head around this new, cloudy way of life, more and more workloads found their way into the public cloud providers, and IT as an industry started to add some new words to our vocabulary. But as you’ll learn, with these new words came some new challenges.
One of the best examples of public cloud use is the mobile apps that run on our smartphones. These apps operate completely independent of any on-premises infrastructure in most cases, are installed and updated directly from the Cloud, and the only impact on the local device is when they are run. Data, state, and logs are all stored in the cloud, providing a central place of collection for management and troubleshooting. The cloud-centric nature empowers development teams to quickly test and deploy updates and maintenance releases more frequently, addressing bugs and rolling out improvements at an accelerated rate compared to a more traditional on-premises approach.
For an example that hits closer to home, let’s use Microsoft’s Office 365. Where IT administrators used to have to install and maintain a monolithic central infrastructure of Microsoft Exchange for e-mail, companies and users can now simply subscribe to Microsoft’s service and get the exact same experience they had before, including all Office applications like Word, Excel, PowerPoint, and begin using Outlook for e-mail with one swipe of a credit card. Moving from on-premises Microsoft applications to Office 365 is, ideally, a transparent transition for the end user. Remember how critical a focus on end user experience is?
It took Microsoft a few years to really nail this service down, but once they did, it really took off. It makes so much sense to operate things this way: offloading infrastructure responsibilities completely from IT departments and merely requiring them to become account managers for user access.
Provisioning Microsoft Office services this way erases all capital expenditure on maintaining an Exchange infrastructure and converts that CAPEX (capital expenditure) into OPEX (operating expenses), which is easier to stomach for many organizations. Considering that almost every user in an organization uses Office and e-mail, this change alone can have a huge impact on budgets, allowing departments to pivot precious capital to other areas of focus. Applying this principle to various aspects of IT gets to the heart of what the public cloud is all about.
For very large enterprises that do not want to place sensitive data in the Cloud, it became a common practice for these companies to build their own cloud-like services, empowering end users with self-service access to request resources, and have automation take over for deployment tasks.
While these types of deployments are usually reserved for only the largest of companies with large IT teams, it became more common with various platforms that came with pre-designed templates that IT departments could build upon to design their own self-service infrastructure offering. While the advantages of a private cloud are obvious, this type of infrastructure comes with downsides, as well. For one, private clouds are almost universally complex. This complexity is frequently a distraction and causes IT organizations to lose focus on the applications, as they are won’t to do.
Hybrid cloud adoption is quickly becoming commonplace. In a survey conducted by ActualTech Media in 2016, 34% of respondents were currently evaluating their hybrid cloud options, and 10% had already implemented something. It’s quite possible that, by this point, the percentage of companies either adopting or about to adopt a hybrid cloud posture has exceeded 50%.
This is exactly what you think it is: a combination of the use of both public and private cloud resources and methodologies. What, when, where, and how much are the common questions. The dilemmas are different and usually weigh each other out based on cost and overall management or privacy requirements.
When you’re running applications in one place, whether it’s the public cloud or your own private data center, it is exponentially less complicated than running that same application in two or more different locations at the same time. You could have users logging in from multiple places in the world, hitting different datacenters. But things need to be kept in-sync as much as possible, and centralized monitoring and management of all available resources and user sessions becomes even more important!
Hybrid Cloud presents some of the most unique demands on IT staff of any current technology. Private and public infrastructure must be monitored for availability, and applications running across all locations must be managed for connectivity and user experience, as well as the load they’re placing on the infrastructure or cloud instance they live upon.
When it comes to keeping track of applications as they exist across multiple infrastructures, it can get very tricky. This is especially true for things like application dependency mapping and resource planning as they can get extremely tricky in a hybrid cloud world.
Applying Application-Centric IT to the Enterprise
When we think of applications running in the cloud, we tend to think of several common key concepts:
- CAPEX vs. OPEX
- Granularity of microservices
As application-centric infrastructure management becomes more and more prevalent, we can begin to draw some corollary between how things are done with apps in the cloud and how they should be done with apps anywhere in the enterprise. When deploying an app in the Cloud, you’re required to define the resources your app is going to need. Of course, you’ll be careful to not overprovision, because that quickly gets expensive. Thankfully, you can often design cloud resources to scale up automatically as the demand on the application grows.
The cloud provides us with a nice roadmap of directives as we chart a course to build our new applications in enterprise IT departments with the full stack in mind.
At Uila we recently published a new book entitled The Gorilla Guide to … Application-Centric IT. In this free book, you’ll learn:
- The advantages of an application-focused approach to IT
- How application dependencies can simplify workload migration and resource planning
- Start the journey of developing a "full stack" mindset for managing applications
- Tear Down the Wall
- Microsegmentation Challenges
- Shadow IT challenge? Take back control
- VDI Troubleshooting: A Deep Dive
- A Datacenter With a View. Not with logging!!!
- App Visibility for the Modern Data Center
- Expensive Disaster Recovery? Change that now.
- Data Center Security Challenges
- Migrate Entire Applications to the Cloud?
- Cloud Induced Application-Centricity Challenges