Table of contents
When Amazon Web Services (AWS) officially launched in 2006, it offered a breakthrough for developers looking to experiment and launch their software projects more quickly and independently. By giving them the ability to provision infrastructure on demand, developers no longer had to wait for infrastructure teams to create an environment to host their application—they could provision infrastructure themselves, instantly.
AWS was designed to remove the capital, infrastructure, and process barriers of starting a digital business, by making it possible for companies to rapidly launch new products and scale with much less effort. It’s no wonder the public cloud services market is expected to reach $191 billion by 2020.1
As more and more companies migrate their applications to the cloud, however, they’re going to realize that the old way of monitoring software performance is no longer going to cut it. This article examines five key changes in the way you’ll need to think about maintaining app performance in the cloud.
1. Server performance will no longer be an indicator of an app’s health
Historically, many operations teams assumed that if the server was functional, then the app must be as well. This is why monitoring was focused solely on servers and infrastructure. But when you move to the cloud, you no longer control the infrastructure, so instead of wanting to know how the servers are performing, you’re going to want to know if your cloud service is meeting the needs of your application. So your first big change is that your IT team’s focus will need to shift toward how your app is performing, rather than how the infrastructure is performing.
2. Applications will live all over the place
If you’re thinking about migrating to the cloud, there’s a good chance you’ll head down the path of a hybrid cloud model, one in which you can leverage both public cloud services while continuing to use your existing private (on-premise) resources. When this happens, however, application components can end up living in various places, and it becomes difficult to get visibility into your entire environment.
Certain tools may be able to monitor the performance of your apps on-premise, but not apps in the cloud, and vice versa. That means you’re going to need an independent, third-party service to act as a source of truth. Ideally, this would come in the form of an application performance monitoring tool that gives you visibility into both on-premise and multiple cloud service providers. This way, you can consolidate multiple disparate tools into a unified view across your entire environment, giving you visibility into your customer’s experience and insight into where your performance bottlenecks lie.
3. Demonstrating accountability will be critical
Once you’re hosting infrastructure in the cloud, your developers are going to find themselves enjoying a whole new level of agility. They’ll likely take advantage of this by making changes in their code constantly. But as they’re doing this, the team should know if that change improved the app or not. Of course, improvement can come in many forms. It could be an improvement in performance, it could be an improvement in features or functionality (in which case, you’d want to know if that feature is getting used or not), or it could mean an improvement in experience (e.g., should the mobile app offer a different experience than our web app?).
If that’s the case, then the number of people involved in the app grows exponentially. It’s not just developers and operations people, but product managers, marketers, and more. And all these people need to be working off of the same data set. They’re going to need the ability to view the data that is relevant to their role so that there’s a level of accountability if something goes wrong. Without this universal view, it’ll be difficult for everyone to stay on the same page and avoid finger pointing. Having a single pane of glass across your organization will help communication across teams and avert finger pointing on contentious issues.
4. Different companies will have different cloud drivers
The imperative to build new relationships, new customer types, and new products has never been more intense. What are your cloud goals? Are you giving developers the ability to create new products?
Or are you re-architecting legacy applications to cut costs (and, in turn, free up resources to make the digital transformation the new CEO demands)? In other words, are you changing your business or are you making room for change?
Either way (and many companies are doing both), you’re going to want to make sure your teams understand which applications can continue with the classic IT mindset and which applications and development teams should focus on creating new customer experiences and revenue streams. This way, everyone’s business goals can be aligned to your cloud strategy.
5. Your dev and ops teams will have a newfound focus on customer experience
Your move to adopt cloud services is driven by a desire for agility and digital transformation. Amazon made its business more successful by getting the infrastructure out of the way, and a multitude of cloud services sprung up to meet that need. Fast-forward to today and it’s no longer cloud services that need to be justified in new projects, but rather, continuing to manage your own infrastructure.
In a similar fashion, monitoring services, logging tools, continuous integration, and security services can now be procured quickly and easily. These services will be crucial in enabling dev and ops teams to focus on the app and not on maintaining and updating ancillary services. So make sure you’re taking advantage of the appropriate tools—they’ll be key in freeing up your dev and ops teams’ time to focus on improving customer experiences.
By now, most companies realize that there’s a lot to be gained in a cloud model. But there’s also a lot that they’ll need to rethink when it comes to building, maintaining, and monitoring performance in their cloud environment.
1. “The Public Cloud Market is Now in Hypergrowth,” Forrester, April 24, 2014.