an application called "cloud-ready" just a form of cloud washing? C'mon - are not all apps "ready for the cloud" (and elsewhere ALL cloud)? Not IaaS and its elastic capacity and automation to solve all the questions application scaling and configuration?
One would think that if you listened to all the honors paid to public cloud these days. But as I dug into the complexities of servicing sophisticated application landscapes, simply place them on a public cloud IaaS contributes to a point.
Why? Because a complex landscape include many servers (often virtual machines) linked by the unique network topology (including load balancing, firewalls, etc.) connected to different storage forms (not to mention storage tiering, backup, etc.) and all choreographed to work together in a specific way with unique rules.
Only your app and ISV architect knows for sure ...
it happens (IaaS and / or PaaS) infrastructure foundations necessary but not sufficient solutions to allow application administrators to fully maintain complex application landscapes in the cloud.
Why? It is because these landscapes are not fully not self-manage the application environment. They interact with the unique configuration of the application rules and procedures. They do not know that only ISV can have on the optimal capacity and topology. And they can not predict changes to do until told to do so. Thus, most cloud hosting scripts - although practical -. Is still but a kludgey solution if you really understand the specific application
And the system gets other layer of complexity when you consider that different (private / public) cloud can include different properties. So if / when an admin wants to redeploy the application on different cloud , he faces another headache
Entry :. ISV App Orchestration
Certainly, I think "orchestration" is another nebulous concept next to "automation" and other terms used more. But in the above context, we examine "App Orchestration" and where it can help. Later, I'll give you some examples of providers that are currently to resolve the problem.
As I mentioned, the best forms of App Orchestration should come directly from the software vendors themselves. Presumably they know the ideal configuration of dynamics, SLA monitoring and more. Specifically, application orchestration (AO) must provide the following:
- Blueprints for landscapes - The engine AO / layer must necessarily begin with the knowledge of the landscape app required and topology - and be able to initiate it. Somewhat similar to CloudFormations AWS, the AO layer must be able to invoke a partial or total application instance - to a specific scale or a given infrastructure. Those plans or models then serve as a starting point for other topologies and / or rules
- operating (or dynamic) orchestration -. At the heart of the AO is logical layer around the optimum settings for the calculation (number and location of applications and virtual machines images), network (including load balancing and quality of service), and storage (connectivity, multi-level caching). The balance of these resources are not necessarily linear, and different use cases the application can impact how these resources are combined. In general, only the architect ISV may have knowledge about these workflows and optimizations
- based automation goals -. Even if you configure an app landscape on top of IaaS, it does not do warranty administrators will not have to adjust in the future. Say you want to re-optimize around a specific SLA (or combination of SLAs). Or want to scale the system in advance of new users. This feature helps to define (and sequence) of future system-goals for States to achieve and maintain
- Multi-cloud deployment -. There are many pure-play vendors currently on the market that facilitate deployment on different public clouds (eg Rightscale, Scalr, enStratus) but no operating from the Administration Console of the application. This allows the admin application for to determine the policy framework own applications , when and where to place workloads on different private clouds and / or public.
- Multi-Version managemen t - Every seller must recognize that large customers with multiple locations will likely be running more than one version of their software. AO must recognize this reality and orchestrate the landscape of instances (or even parts of the landscape instances) that can have different versions
- multi-tenant management -. Again, a supplier must recognize that most customers (particularly service providers, sis, etc.) are likely to need to manage / isolated tenants separated on infrastructure. AO must recognize it not as an administrator perspective role-based (a prerequisite), but the maintenance point of view of the isolation of a landscape while being able to manipulate another
Next .: Orchestration Suite
I also wanted to share a brief thought here :? What would a software suite "cloud-ready" like
We all know that the major suppliers of software and platforms (think: Oracle, SAP, Microsoft, Symantec, Citrix CA, IBM, HP, etc.) offer tons of what they call software from end to end. They all say that their SW is integrated. But can they all claim that these suites are cloud-ready? Can they all be orchestrated as an integrated system together? Probably not. Not yet anyway. Which leads me to the next section ...
App Orchestration: A new (required) layer for ISVs
Traditionally, independent software vendors (and their customers) have had focus on code, on API, performance tools, and remote management / monitoring.
However, during the recent era virtualization , the push was for software companies to go further and ensure that their applications can be virtualized and supported in a fully virtualized data center.
As we are now entering the Cloud Era , I think software vendors deliver complex applications and / or application suites will be necessary to provide intelligent orchestration when the application portfolios are run in a cloud environment. This means "north-south" orchestration, namely how the software interacts with the IaaS / PaaS layers, and "East-West" orchestration, namely how the software interacts with other components / products supplier.
The "East-West" coordination is what I find most fascinating. This could mean the orchestration continues between specific applications and networking, storage, firewall, IaaS, and DB. Through all products from a given software suite ISV.
This would change the concept of "suite" of a supplier to be a loose aggregation of applications and tools, to one that was indeed ready Cloud- and orchestrated as a system. Even if only for use with a cloud on premesis.
Do the vendors are beginning to accept the need for real orchestration in a cloud? I hope. Software vendors are really the only ones with the deep knowledge to do so. And the Cloud era, value to customers would be immeasurable.
Other Resources
- App Orchestration Concepts [Blog] Ashish Gujarathi
- Wikipedia on orchestration
- IBM developerWorks on cloud orchestration [Blog]
- ISVs do this?
- OASIS specification topology and orchestration for cloud applications (TOSCA)
0 Komentar