Enterprise CMDBs and the Cloud: APIs will Keep Us Together

By Richard Seroter, Senior Product Manager. Find Richard on Twitter

While the cloud has become a welcome channel for companies refining their server footprint, it’s still rare to find an established business that is running *solely* in the cloud. Rather, many companies leverage the cloud for specific workloads and new cloud-first applications, while keeping other servers and applications in-house. But are you tracking your cloud servers the same way you track on-premises ones? Do you have a single place to see a list of ALL your servers and when they last changed? Configuration management databases (CMDBs) are a popular way to store information about IT assets such as who owns them, where they physically are, and their change history. How can you take advantage of the cloud while retaining a complete, up-to-date CMDB? One option is to programmatically link cloud servers to your CMDB through the use of cloud APIs. In this blog post, we’ll see an example of that process in action.

Step 1: Link Cloud Servers to CMDB Entries

Let us first consider the “IT-as-a-Service” scenario where an internal customer portal serves as the launching pad for new cloud servers. Using the Tier 3 API, customers can easily provision and manage their cloud servers without ever logging into our Control Portal.

Here, the customer’s own portal gives internal employees the opportunity to quickly spin up a cloud server. After adding a record to the CMDB and getting back the CMDB record locator, the Tier 3 CreateServer API operation is called. Tier 3 servers can have user-defined metadata attached to them, and in this case, that metadata consists of the CMDB record ID.  The server build request is queued by the Tier 3 engine and the name of the new server is returned by calls to the GetDeploymentStatus API operation. The name of the Tier 3 server can optionally be added to the CMDB configuration item in order to create a bi-directional link between the systems. At this point, the internal CMDB has a list of servers built internally or in the Tier 3 cloud.

Step 2: Synchronize Updates

A wonderful aspect of the cloud is the ease by which someone can create, modify, and destroy servers on demand. This means that you do not want to get stuck manually maintaining records of cloud servers that are constantly in flux. Inevitably, the effort to keep the CMDB up to date will fail and it becomes an unreliable record of IT asset configurations. How can you easily synchronize your CMDB with Tier 3? Use the APIs!

Tier 3’s Engineering team just added new API operations that make it simple to retrieve a list of all servers that have changed within a certain period of time. Customers can run a simple application every evening and invoke the GetAllServersByModifiedDate API operation to pull back a list of all Tier 3 servers that have experienced the following events:

 
• Created or deleted
 
• Paused/powered on/powered off/reset/rebooted/shut down
 
• CPU count, RAM amount, storage amount changed
 
• Public IP added or released
 
• Snapshot created/restored/deleted
 
• Archived or restored from archive
 
• Custom (metadata) field added, or value changed
 
• Software installed or script executed (via Blueprint)

Most of these changes are extremely relevant to a configuration database and provide critical context about the cloud server’s lifecycle. By automating these changes with the API, you can save significant administration time and effort.

CMDBs are a critical component for many enterprises, and your cloud servers should be a visible part of your IT asset management strategy. Tier 3 is constantly working to deliver a powerful API that provide the glue to connect your on-premises systems and cloud resources. Existing customers have instant access to our API today and new customers can get started by signing up for an account today!

Look Beyond the Sticker Price: What It REALLY Costs to Run a Cloud App

By Richard Seroter, Senior Product Manager. Find Richard on Twitter

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.

Example application

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.

Cost breakdown

“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. Tier 3 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. Tier 3 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:

 
1. 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. Tier 3 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. Tier 3 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.
 
2. 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.
 
3. Automate mundane server management tasks. Running maintenance scripts or installing software on a cluster of servers is time consuming and tedious. Tier 3 provides an innovative Group capability that makes it possible to issue power commands, install software, and run scripts against large batches of servers.
 
4. 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 Tier 3 for example, customers can define the maximum amount of vCPUs, memory, and storage that any one Group can consume.
 
5. 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 Tier 3 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, Tier 3 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.

Summary

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 Tier 3 a try and see if our innovative platform is exactly what you’re looking for!

The 8 Steps to Offer Your Own Branded Enterprise Cloud

By Richard Seroter, Senior Product Manager. Find Richard on Twitter

Are you an MSP, VAR, or systems integrator? Do you want to start offering cloud services to upsell existing customers, while attracting new ones? Tier 3 is here to help. Last week, we announced a Reseller Edition of our cloud and we offer unique expertise in partnering with companies that want to quickly add cloud services to their product portfolio. In this blog post, we’ll walk through 8 quick steps to follow in order to get up and running as a cloud reseller.

1. Investigate the market and select a reseller.

We recently did a reseller-focused webcast with the folks at Talkin’ Cloud and a spot survey showed that over 75% of attendees were actively looking for a cloud partner. Clearly, a large number of telcos, SIs, and regional service providers are scouring the market and aggressively assessing whom to partner with.

If you are looking for a partner, what should you be asking each vendor? How can you ensure you are partnering with an innovative, differentiated provider that can bring you new revenue over the long-haul? Here’s a great starting point:

Does the provider have a global set of data centers?

WHY THIS IS IMPORTANT: Your customers are more global than ever, and physical locations close to users and customers matter. Also, data sovereignty regulations impact where the physical “host” servers need to be.

Can the provider support the complex infrastructure and networking needs of your managed customers?

WHY THIS IS IMPORTANT: If not, there’s a good chance your customers won’t find your new cloud services attractive for their enterprise workloads.

How often to legacy systems need to be re-architected to fit the provider’s cloud?

WHY THIS IS IMPORTANT: Agility and immediate access to resources are key drivers to move to the cloud in the first place. But this doesn’t need to be at odds with legacy applications - even complex environments can be migrated cleanly to the cloud if you choose the right provider.

What controls do you have in place to protect data sovereignty?

WHY THIS IS IMPORTANT: Larger businesses need peace of mind to know their data is securely stored in isolation, in a physical location they can specify.

Which 3rd party products are commonly added by the provider’s customers, if any?

WHY THIS IS IMPORTANT: Add-on services can be helpful for specific scenarios, but when it comes to the core scenarios of cloud management and automation, you should look for a provider that has significant capabilities built-in. Bringing in extra modules just adds cost and complexity for you and your customers.

How does the partner manage customer accounts and billing processes?

WHY THIS IS IMPORTANT: These back-office functions are vital when it comes to quickly monetizing the service. Sure, it’s not a sexy set of features, but it will make invoicing a breeze.

Can I rebrand the provider’s offering and make it look and feel like something from us? Does this feature cost extra?

WHY THIS IS IMPORTANT: This is key to customer loyalty and building brand equity.

How do I make money with your cloud?

WHY THIS IS IMPORTANT: Powerful features and a highly capable global cloud platform don’t mean anything without a competitive partner program, and a spirit of partnership with your selected vendor.

How can I extend my business model of value-added services to the provider’s cloud?

WHY THIS IS IMPORTANT: This last question is key. How can you make sure that customers don’t just use a commodity cloud offering, eliminating your unique expertise? Among other things, Tier 3 encourages customers to differentiate on price and by offering exclusive intellectual property through Blueprints that encapsulate best practices on building highly-available, tuned application environments.

2. Evaluate Tier 3 - sign up for an account.

This one’s easy! Just visit the self-service sign up page and register for a new Tier 3 account.  Within moments, you will receive an email with temporary credentials and a link to the easy-to-use Tier 3 Control Portal.

3. Change the site aesthetics to fit your brand.

Once you’ve logged in, the first thing to do is customize the Control Portal UI to match your brand. Tier 3 offers a variety of settings that allow you to rename the interface, modify logos and shortcut icons, and alter the color scheme of the site. These superficial – but important – changes go a long way to maintaining a brand identity with your customers.

4. Update the support-related hyperlinks.

Your will likely want your customers to take advantage of the support experience that you currently offer. Fortunately, you can easily override existing support links and point to your own online assets. For instance, you can change the default support email address, phone number, knowledge base URL, chat service URL, and much more.

5. Update outbound email templates.

Each email that comes from the cloud platform should reflect your brand and message. To achieve this, Tier 3 added configurable settings that let you change the email addresses, signature, subject lines, and message body of the most common system alerts.

6. Integrate with your existing billing, configuration management, and identity systems.

Unless you want to build a silo cloud service that doesn’t integrate with the rest of your back office systems, you’ll want to pay careful attention to this  step! To integrate your billing systems with Tier 3, consider using our helpful Billing API that gives you access to usage estimates and monthly invoices. While you can easily access and download invoices from the Tier 3 Control Portal, the Billing API gives you a way to directly integrate our cloud with your financial systems.

Many organizations have investments in change management or support systems that track assets throughout their lifecycle. How can you ensure that servers in the Tier 3 cloud are properly “tagged” and linked to a configuration management database? One useful option is to add account-level “custom fields” that are populated whenever servers are added to the Tier 3 cloud.

You can access these custom field values through the Tier 3 API as well. If you chose to provision servers from within your own custom portal, you could call the Create Server API and tag the server with an identifier from your own system. This makes it simple to reconcile changes to servers in the Tier 3 cloud with the entries in your local systems.

Finally, if you offer a centralized identity directory to authenticate users of your existing platform, you may want to reuse that with the Tier 3 cloud. Tier 3 supports the SAML identity protocol for single sign-on between external identity directories and the Tier 3 Control Portal. Consider SAML and SSO if you want to make it simple for customers to reuse their existing credentials to log into the Tier 3 Control Portal.

7. Choose your preferred data centers.

You’re nearly ready to open the doors of your new cloud offering! In this step, assess which data centers you want customers to deploy servers into. The “Preferred Data Centers” settings let you choose which data centers show up for users who provision and manage servers.

8. Establish cloud costs and promotions.

While you likely established contractual settings early on, this final step involves configuring pricing details in the platform. We offer a very competitive pricing plan that ensures that you can generate a strong recurring revenue stream while giving customers a cost-effective cloud solution. Contract terms and promotion codes are managed by Tier 3 but we work closely with you to rapidly apply pricing parameters to your account.

Summary

The cloud offers a compelling and lucrative opportunity for existing managed service providers and systems integrators. Instead of building and maintaining your own cloud, consider partnering with Tier 3 and bringing cloud services online in a matter of days or weeks!

Codenvy Cloud IDE Now Directly Supports Tier 3 Web Fabric PaaS

By Richard Seroter, Senior Product Manager. Find Richard on Twitter

Just a couple weeks ago, we looked at how Platform-as-a-Service (PaaS) helps developers rapidly build and deploy applications to the cloud. We also covered a new breed of cloud-based development environments (IDE) that developers can use to create and publish their web applications. Since then, the cloud-based IDE we featured – called Codenvy – has updated their product to support the Tier 3 Web Fabric. In this post, we’ll walk through how to quickly and easily deploy and manage Web Fabric applications from your web browser.

To start with, when users of Codenvy start a new web application project, they are asked which technology they want to use, and then which PaaS to deploy to. At this moment, the Tier 3 Web Fabric is available for Java Web Application (WAR), Java Spring, and Ruby on Rails projects. Note that Web Fabric works with more environments than these three, but these are the technologies supported via Codenvy.

Once the user chooses the technology and corresponding PaaS, they choose a simple project template (if one exists for that technology), and are then asked for the management API endpoint of the Web Fabric environment.

The project framework is then created, and the user is prompted for their Web Fabric credentials. After providing a valid username and password, the application is deployed and Internet-accessible. All of this in matter of seconds! To update the application, developers visit the PaaS menu option and choose Tier 3 Web Fabric.

From the subsequent window, developers can modify the name, URL, and memory allocation of the application. Additionally, the application can be started, stopped, deleted, and updated. It’s also possible to add Web Fabric application services – such as RabbitMQ for messaging or Microsoft SQL Server for relational database storage – to a project.

Codenvy can also be used as a simple management interface for any applications running in Web Fabric. This can come in handy if you’re on a shared machine without the typical Cloud Foundry management tools available!

This interface shows you each application running in your Web Fabric environment, and lets you start, stop, restart, or delete it.

Summary

We’re excited to be a supported part of the innovative Codenvy platform and think that this lowers the barrier to entry for our customers while making it simpler for developers to build amazing applications in any language of their choice. Want to try it out? Sign up for a free Codenvy account and then take Web Fabric for a spin!