“Getting a little bit of the right information just ahead of when it’s needed is a lot more valuable than all the information in the world a month or a day later.” That quote – found in the book The Two Second Advantage by Vivek Ranadive and Kevin Maney – highlights a new reality where responsiveness can be a competitive advantage. Smart companies are building a responsive IT infrastructure where data isn’t just hoarded in massive repositories, but analyzed quickly and acted upon. How can you know more, faster and have better situational awareness?
With an increasing amount of critical IT systems running in the cloud, there’s a need to know what’s happening and act on it. This month, CenturyLink Cloud introduced Webhooks, making us among the first public IaaS cloud providers to send real-time notifications to a web service endpoint. For this initial release, customers can set up Webhooks for events within accounts, users, and servers.
When To Use This?
Webhooks are relatively new idea, although already used by diverse web properties like Wordpress and Zoho. Let’s look at three different scenarios where CenturyLink Cloud Webhooks can lead to better decisions.
Scenario #1 – Data Synchronization
Polling is an inefficient way to retrieve data from an external system, but it remains a popular choice. When you poll a system for changes, you’re effectively asking “do you have anything new for me?” Many times, the answer is “no.” With push-based notifications, the only time you are contacted is when something relevant happens. For example, some customers synchronize CenturyLink Cloud data with their internal support or configuration management systems. They do this for auditing purposes, or to give support staff an accurate picture of cloud deployments. The issue? Staying in sync requires an aggressive polling frequency that needless encumbers systems. Webhooks provide a better alternative.
In the scenario visualized below, as soon as a new server is created in the CenturyLink Cloud cloud, an event fires and a message is sent to an endpoint specified by the customer. That listener service then updates the appropriate internal system. Within seconds, systems are completely synchronized!
Scenario #2 – Anomaly Detection
People love the cloud because of the self-service capabilities and freedom to instantly create and delete servers at will. One downside of this freedom – for service providers anyway – is fraudulent signups. CenturyLink Cloud resellers actively monitor new accounts, but the sheer volume of manual analysis can be daunting. What if resellers could programmatically monitor specific sequences of events and then use that data to flag an account as “suspect” and deserving of special attention? Again, we turn to Webhooks to help react faster.
It’s great that developers can quickly bring gobs of new cloud machines online. But rapid provisioning can occur within the wrong sub-account or under unusual circumstances. In both of these examples, consider using a complex event processing solution that monitors streams of Webhook events and detects aggregate patterns that reveal more than any single event can.
Scenario #3 – Compliance Monitoring
Cloud and governance don’t have to be at odds with each other – and in fact, these two ideas go hand-and-hand when it comes to IT as a service. CenturyLink Cloud already provides customers with many ways to do this today through sophisticated account management capabilities. But we often get customers requesting a “corner case” scenario – like preventing a certain user from being added to an account, or making sure that database servers aren’t given a public IP address. Webhooks are a way for us to programmatically empower customers to support unique scenarios, in self-service fashion. Via Webhooks, users compare events to previous ones using a data repository. This way, customers can immediately find out if a server was changed inappropriately, a user was added to an account, or the contact information was changed. If an out-of-compliance change is made, the customer can respond almost instantly!
It’s very simple to configure Webhooks in the CenturyLink Cloud cloud. Simply visit the API section of the Control Portal and choose Webhooks. Here, users can browse the list of available Webhooks, then specify the “target” URL to receive a JSON-encoded message. Each Webhook is configured with an HTTPS URL, and includes an optional capability to send events that occur within sub-accounts.
For more details on how to create a Webhook listener service, take a look at our Webhook FAQ article in the Knowledge Base. This is an innovative and exciting capability for the platform and we can’t wait to see how customers use it to create more responsive systems and processes!
Elasticity is a core tenet of cloud computing. Cloud has become so popular simply because resources can be adjusted up or down, based on business need, instantly. Manually resizing cloud environments is still MUCH easier than altering physical hardware. But human action is still required, adding human cost to cloud.
A few cloud vendors have attempted to automate this process through “auto scaling” – services that expand and reduce the size environments based on user-defined parameters. However, this capability by and large automates the addition and removal of virtual machines to an existing resource pool. In engineering terms, this is “horizontal scaling” – adding capacity across multiple virtual machines. This approach is useful for consumer applications (think Netflix scaling up for Saturday night), but the enterprise scenario is much different, as we found out in our market research when developing this feature.
While we always recommend that our customers build highly available cloud systems with no single points of failure, there is value is sizing those resources up and down (i.e. “vertical scaling”) instead of only being able to add or remove entire servers. Having multiple servers is key for fault tolerance, but some workloads can benefit from additional server capacity, not just more servers!
This month, CenturyLink Cloud introduced our new Autoscale service. The initial release is focused on vertical scaling of CPU resources, with more vertical scaling (and, yes, horizontal scaling!) on the roadmap. Today, you can now add and subtract CPUs from cloud servers based on user-defined utilization limits. Capacity is added instantly without a reboot and capacity is removed only during user-defined windows of time, to prevent a reboot from occurring during prime usage hours.
Companies embrace the cloud because it offers agility, speed to market, self-service, rapid innovation, and yes, cost savings. There are plenty of cases where organizations can save money by using cloud resources, but it’s easy to focus on vendor compute and storage pricing, and forget about all the other financial components of a cloud application. See Joe Weinman’s Cloudonomics for an excellent analysis of how to assess the economic impact of using the cloud. An application can very easily cost MORE in the cloud – but that might still be just fine, since it helps the business shed some CapEx and remove servers from corporate data centers. In this post, we’ll talk about the full scope of pricing cloud applications and give you a useful perspective for assessing the overall cost.
Businesses deploy applications, not servers. A typical application is comprised of multiple servers that perform different roles. For instance, let’s consider an existing, commercial website that receives a healthy amount of traffic. It uses a load balancer to route traffic to one of multiple web servers, leverages a series of application servers for caching and business services, and uses a relational database for persistent storage.
To maximize revenue and customer satisfaction, the application is replicated in another geography for availability reasons and traffic can be quickly steered to the alternate site in the case of a disaster or prolonged outage.
“Hidden costs” often bite cloud users. This is especially true for those who buy from a cloud that offers “cheap virtual cores!” but also require you to buy countless other services to assemble an enterprise-class infrastructure landscape. Let’s look at each area where it’s possible – and likely – that you will incur a charge from your cloud provider.
- Application migration. If you are doing greenfield development in the cloud, then this won’t apply. But if you have existing applications that are moving to the cloud, there are a few migration-related costs. First, there can be a labor cost with doing virtual machine imports. Some cloud providers let you import for free, others charge you. In most cases, there is also a bandwidth charge for the transfer of virtual machine images. Finally, there’s likely a cost for storing the virtual machine image during the import process.
- Server CPU processor. This – along with RAM – is the number most frequently bandied about when talking about the costs of running a cloud application. Some providers let you provision the exact number of virtual CPU cores desired; others provide fixed “instance sizes” that come with a pre-defined allocation of CPUs and memory.
- Server memory. Cloud providers are ratcheting up the amount of RAM they offer to address memory-hungry applications, caching products, and in-memory databases.
- Server storage. There are many different types of storage (e.g. block storage, object storage, vSAN storage) and costs vary with each. Don’t forget to include the cost of storing data backups, virtual machine templates, and persistent disks that survive even after servers have been deleted.
- Bandwidth. It’s easy to forget about bandwidth, but it’s a charge that can bite you if you’re not expecting it! You may need to factor in public bandwidth, intra-data center bandwidth, inter-data center bandwidth, CDN bandwidth, and load balancer bandwidth. Not all of these may apply, and some may not be charged by your cloud provider, but it’s important to check ahead of time. Most cloud providers use the “GB transfer” model, charging for all data transferred – and penalizing customers for bursting above their commitments. CenturyLink Cloud utilizes the 95th percentile billing method, preventing surges in traffic from grossly affecting costs.
- Public IP addresses. Nearly every cloud provider offers a way to expose servers to the public Internet, and some charge for the use of public IP addresses. This is usually a nominal monthly charge, but one to consider for scenarios where there are dozens of Internet-facing servers.
- Load balancing. There is often a charge to not only use a load balancer, but also for the traffic that passes through it.
- VPN and Direct Connect. Cloud users are looking for ways to connect cloud environments to on-premises infrastructure, and vendors now offer a rich set of connectivity options. However, those options come at a cost. Depending on the choice, you could be subjected to fees for setup, operations, and bandwidth associated with these connections.
- Firewalls. This is usually baked into each cloud provider’s native offering, but you will want to check and make sure that sophisticated firewall rules don’t come with an additional charge.
- Server monitoring. Even those cloud servers aren’t in your data center, it doesn’t mean that you don’t need to monitor them! Depending on your monitoring needs, there can be a range of charges associated with standard and advanced monitors for each cloud server.
- Intrusion detection. Given that cloud servers are often accessible through the public Internet, it’s important to use a defense-in-depth approach that includes screening incoming traffic for potential attacks. CenturyLink Cloud is a bit unique in that we offer this at no cost, but you can still get this sort of protection from other vendors – but rarely for free.
- Labor for integrating with on-premises assets. You don’t want to create silos in the cloud, and you will likely spend a non-trivial amount of time integrating with your critical applications, data, identity provider, and network. If this effort requires assistance from the cloud provider themselves, there could be a charge for that time and effort.
- Distributed, disaster recovery environments. Applications fail, and clouds fail. If you require very high availability, you may need to duplicate your application in other geographically-dispersed cloud data centers. You could choose to keep that environment “warm” by synchronizing a data repository while keeping web/application servers offline. Or, you may choose to build a truly distributed system that leverages active infrastructure across geographies. Either way, it’s possible that you’ll incur noticeable charges for establishing replica environments.
- Development / QA environments. Applications may run differently in the cloud than in your local data center. Hence, you could choose to provision pre-production environments in the cloud for building and running your applications.
- System administrator labor costs. One of the wonderful things about the cloud is the widespread automation that makes it possible to provision and maintain massive server clusters without adding to your pool of system administrators. However, there are still activities that require administration. This may involve server patching and software updates, deploying new applications, and scaling the environments. Some of those activities can be automated as well, but you should factor in human costs to your cloud budget.
Places to save money
Given the various charges you may incur by moving to the cloud, how can you optimize your spend and take full advantage of what the cloud has to offer? Here are five tips:
- Don’t over-provision. Gone are the days when you have to request a massive server from an internal IT department because you MAY need the extra resources in the future and don’t want to deal with the hassle of upgrading the server later. CenturyLink Cloud makes it simple to change the number of virtual CPUs, amount of RAM, or amount of storage in seconds. Only spend money on what you need right now, and only pay more when you have to scale up. In addition, don’t settle for cloud providers who force you into fixed “instance sizes” that don’t deliver the mix of vCPU/RAM/storage that your application needs. CenturyLink Cloud encourages you provision whatever combination of vCPU/RAM/storage that you want! In fact, we usually tell customers to under-provision to start with, and ratchet up resources as needed.
- Turn off idle servers. If you decide to create development or QA environments in the cloud, it’s likely that those environments will be fairly quiet over weekends. By shutting those down – and doing it automatically – you can potentially save hundreds or thousands of dollars per year.
- Automate mundane server management tasks. Running maintenance scripts or installing software on a cluster of servers is time consuming and tedious. CenturyLink Cloud provides an innovative Group capability that makes it possible to issue power commands, install software, and run scripts against large batches of servers.
- Add resource limits to prevent runaway provisioning. Elasticity is a foundational aspect of cloud computing, but it’s not a bad idea to establish resource caps. With CenturyLink Cloud for example, customers can define the maximum amount of vCPUs, memory, and storage that any one Group can consume.
- Carefully consider uptime requirements and disaster recovery needs. Even though the cloud makes it easier, it’s still not cheap or simple to build a globally distributed, highly available application. Evaluate whether you need cross-data center availability, or, a defined disaster recovery plan. The simplest solution for CenturyLink Cloud customers is to provision Premium block storage which provides daily snapshots and replication to an in-country data center. In the event of a disaster, CenturyLink Cloud brings up your server in an alternate data center and gets you back in business. If you want to avoid nearly any downtime, then you can architect a solution that operates across multiple data centers. To save money, you could choose to keep the alternate location offline but synchronized so that it could quickly activated if needed.
When considering all the services you need to deploy and operate enterprise-level business applications, the “cheap virtual cores!” pitch is less compelling. It’s about finding a cloud provider that offers an all-up, integrated offering that gives you the set of services you need to deploy and maintain a robust, connected infrastructure. Give CenturyLink Cloud a try and see if our innovative platform is exactly what you’re looking for!
In the coming months, CenturyLink Cloud will launch new, enterprise monitoring capabilities, powered by ScienceLogic and New Relic. We wrote a guest blog post for ScienceLogic, describing our approach to monitoring, check it out here.
New Relic has become a real leader in website performance analytics, and CenturyLink Cloud is thrilled to incorporate this service, for free, into our Platform as a Service service. For each application deployed to Platform as a Service, regardless of the language/framework that the application was written in, New Relic captures deep information about response time, throughput and more. While we’ve put some of the most interesting statistics directly in the CenturyLink Cloud Control Panel for at-a-glance viewing, we also enable you to drill right through to the New Relic site and discover even more valuable metrics. In this post, we’ll take a quick look at how we’ve incorporated New Relic’s monitoring data into the CenturyLink Cloud Control Portal.
Previously, Platform as a Service users had a simple set of metrics about their running application(s) that included how much memory, CPU and storage was allocated for a given application.
This resource allocation information is important, but application owners also REALLY want to know how well an application is performing for their users! The brand new Control Panel dashboard shows a subset of the New Relic metrics that begin to give you a picture of an application’s health.
You can now see advanced metrics like website response time, throughput (pages requested per minute), error rates, Apdex and more. When you first create your Platform as a Service environment, we automatically provision a New Relic account for you at no cost. Therefore, when you click the “New Relic” button at the bottom of this page, we perform a single-sign-on with New Relic and drop you right into their feature-rich dashboard environment.
From here, you can discover even more data points about a deployed application(s). You can drill into individual pages of the application and view a wide range of different reports.
Interested in seeing how the client’s browser is spending its time requesting and loading your application? There’s a report for that.
Curious as to the performance of the application for the global audience? There’s a report for that.
We at CenturyLink Cloud are very excited by this partnership with New Relic and we hope that you’ll find these advanced metrics extremely useful when monitoring and optimizing your PaaS applications deployed to Platform as a Service.