As the range of cloud providers and services continues to grow, making choices and managing more and more complex infrastructures becomes a big challenge. Balancing business requirements with the technical pressures can sometimes feel impossible. Scalr, alongside other multi-platform orchestration tools like Heroku and Terraform, can carry some of the burden.
Here some of the challenges that I often see:
Because of the complexity, there is a higher likelihood of critical mistakes occurring. Someone may open the wrong ports or might leave the server running during a long weekend, exposing your data to potential hackers. If you are working in any kind of cloud environment, I’m sure you can easily add plenty of your own horror stories.
Keep reading. I am not here to rehash well-known challenges, but to offer some wisdom. There are solutions available in the market that address the complex challenges we all face. Scalr is one excellent example, and I recommend you find out what it can do.
Scalr is a Cloud Management Portal for managing multi-cloud infrastructure. Think of it is a single window for all cloud environments. If you are using multiple cloud providers for hosting your application, then Scalr can be used to provision, manage, and monitor the application and the corresponding infrastructure.
Scalr supports the following cloud services: Amazon EC2, Google Compute Engine, Rackspace, Open Cloud, Microsoft Azure, OpenStack, Nebula, CloudStack, IDC Frontier, and Enter Cloud Suite. Scalr comes in three flavors: hosted Scalr, Enterprise Edition, and open source Scalr. More details on pricing and support can be found here.
Sometimes people think Scalr is only beneficial when you’re working with multiple clouds. This is not accurate. Take my word for it: Scalr can pay its way even for people dealing with a single cloud provider. Let’s explore some of its features.
Below are some of the features I personally feel are the most useful:
Using the Scalr Orchestrating engine can trigger actions against a defined target. For example, while bootstrapping your instance (for an application server, perhaps) you might want to trigger some actions like registering with off-site services (like monitoring tools), or you may want to notify other webservers. This is very easy to configure in Scalr. These actions can be defined like scripts, hence you are free to choose your own scripting language.
The abstraction of the Scalr UI helps you deal with similar classes of services on multiple cloud platforms with little prior experience. Your experience creating or managing volumes in AWS might not be helpful for working with volumes in OpenStack. If developers aren’t comfortable with OpenStack it may take some time for them to do get up to speed. The same holds true for the respective API calls. Scalr, however, provides a menu-driven interface, as well as, an API to manage such scenarios.
Let’s take another example. Suppose you have to deploy a three-tier application in your multiple-cloud environment. Imagine you want to provision your web servers and app servers in AWS, but you want the database to be in OpenStack. Scalr will offer you a single window to set up both platforms. This is a very simple scenario, challenges in real life can be infinitely more complicated with increased components like cache servers, and monitoring server across various platforms.
Cost is one of the major reasons why customers move to the cloud. Because of this, it becomes critically important to provide customers with detailed analysis of resource consumption and costing. If you are using multiple clouds, I’d bet it’s not easy to pull a single summarized report of resource usage and the costs for different cloud platforms. The Scalr Cost Analytics Dashboard shows you exactly how much you are spending on all your public and private clouds.
I am most familiar with AWS, so I’ll use an AWS example here. In AWS you need to tag your instances while launching them so that they can be visible for various reports. Normally developers don’t keep up with tagging because it is tedious. Scalr automatically adds tags to your resources. Tags can include business unit, resource owner, and application.
Scalr enables single sign-on (SSO) across your public and private clouds. If you have an existing identity management system like LDAP, then Scalr grants your users access to the organization’s cloud resources based on the LDAP groups to which they belong.
I hope I’ve helped familiarize you with Scalr and the wonders it can perform. I promise a much deeper dive and more Scalr details in some upcoming blog posts. In the meantime, start thinking about the best ways of managing multiple cloud environments and perhaps generate some excitement about solving common problems we all confront. Any comments? Leave them below.
It's Flash Sale time! Get 50% off your first year with Cloud Academy: all access to AWS, Azure, and Cloud…
In this blog post, we're going to answer some questions you might have about the new AWS Certified Data Engineer…
This is my 3rd and final post of this series ‘Navigating the Vocabulary of Gen AI’. If you would like…