With the Agility Platform, Blueprints are a way for application owners to drag and drop the technologies and components required to deploy a new instance of the application or service offering. This may be something simple, like an internal website that needs an operating system, Web server, maybe a load balancer. Or it may be something more complex, like a fully integrated Customer Relation Management System (CRM) that requires many instances, technologies in the instances, networking, storage, firewalls, etc.
Sure, there is more to it than dragging and dropping technologies like tomcat, mysql, etc., but from a high level, that is the starting point.
The application owner has two options for the foundation:
- Use as many of the single provider’s features and functionality as possible to have a cohesive and fully integrated solution; or
- Drag and drop the additional services (load balancing, firewalls, networking, etc.) from multiple vendors based on internal standards, favoring one technology over another
Suppose you are using public cloud provider ABC Corp. The company has been great to you, the pricing works well and support is there when you need it. Will it remain like that a year or two down the road? Maybe. But suppose the provider raises its rates, starts to become unreliable, becomes less innovative or that the overall service does not meet expectations. It might be time to move on.
While Blueprints are portable, there are limits. For instance, an operating system with environment variables, network settings, storage settings, even technologies such as a Web app or a database dragged and dropped onto them, tend to be portable from one provider to another. When Blueprints start pointing at other services the provider has, such as a load balancer, the settings tend to be provider-specific.
Sure, another provider may have a load-balancing service (or not), but the features of the service and/or the way you configure it may be different. If they are and you switch providers, you will have to go into the Blueprint to do some minor updates. Not really a big deal … unless you have hundreds of Blueprints.
Some of our customers want to limit potential re-work of Blueprints in the event that they change cloud providers in the future. They use the core features of the cloud provider, such as provisioning instances, setting scale up/down settings, DHCP, storage, technologies required for the application, etc. Then for other features they need, such as specialized networking or load balancing, they want to use a more portable, non-cloud-provider-specific solution, such as F5’s Local Traffic Manager.
The Agility Platform provides several general integrations to meet these needs. Also, the Agility Platform SDK allows customers to build tight API-based integrations themselves. Lastly, based on the customer’s requirements, some custom policies may be all they need.
In the end, there really is no wrong way to build a Blueprint when it comes to the additional services it may need. It comes down to what the implementation requirements are and which options best fit the organization’s needs today. Keep the future in mind but don’t get stuck on it.
Worse case you have to update some Blueprints … or maybe not.
– Tobin Isenberg