Sucked into work, travel, study cycle for a month, did not have breathing room for blog post. Lets see how this month goes…
Deployment involves asset or resources associated with a process. Most enterprise is continuously seeking to improve the separation between the Assets / Resources from the process. The enterprise consist “n” number of vendor products and each one of products has “n” of ways to deploy it. In most cases, the Meta data associated with Process + Asset / Resources only usable for that instance and no portability. In today’s cloud environment it is no different. Declarative deployment provides the separations of the concerns with asset and process, in other words the asset is self-contained, when you move from one environment to another regardless homogenous or heterogeneous environment should continue deploy. In today’s environment declarative deployment is possible with homogenous stack, not possible heterogeneous stack. If you buy in or marry one specific vendor declarative deployment – i.e clear separation between the asset / resource wrt process you should able to achieve feasible declarative deployment. Again these are holds true when you operating in private cloud – i.e you have absolute control. In the cloud eco system, there is strong need for standards – Declarative Deployment Standards are one of the key ones. Lack of standards in cloud deployment space will keep declarative deployment mostly as concept.
There is some level of discussion in comparing and contrasting whether PaaS != Application Server – read it here, here, here
If I give example it would be equivalent of comparing city vs state (Often my 4 year old son tend to confuse between the Country vs State vs City). Application Server is a product, which can be installed, configured, migrated, etc. Whereas PaaS is not single product – it is combination of products, processes and standards. Certainly application server can be one of the products in the PaaS. In other words, application can participate in the PaaS layer. Moreover you can define what is Application Server? With PaaS all you can define the characteristics of PaaS, not the PaaS itself. If you try defining the PaaS it will become Blind Men Elephant Story.
On the side note: Amazon recently released the new offering Elastic Beanstalk and many of them call Amazon’s PaaS. It is the all the bells and whistles of Amazon offerings such as load balancing, autonomic scaling, audit, monitoring + Linux + apache tomcat with deployment of WAR file with tight integration with Eclipse IDE
For a while I had been thought of posting this blog – about the IaaS (Infrastructure-as-a-Service) and PaaS (Platform-as-a-Service) life cycle. Higher level of IaaS life cycle is a typical hardware life cycle – Planning, Procurement, Imaging – Install, update, delete, hardware maintenance and EOL. But the subset of the imaging – virtual machine has its own large life cycle. The virtual machine life cycle differs based on your vendor pitch or vendor Virtual machine life cycle management product that you buy in. But at the core of virtual machine lifecycle – Create, Start, Stop, Update, Delete (EOL). When you create the VM instance you will eventually assembling various software components – i.e VM templates. There are several ways to assemble VM templates in the life cycle context. Let’s take example of Middleware
- Start with base OS
- Start with base OS + Middleware Software Install
- Start with base OS + Middleware Software Install + Configured
- Start with base OS + Middleware Software Install + Configured + Application Deployed
Starting at each one of the VM template has its own pros and cons at given place of life cycle – Dev, Test and Prod along with enterprise practice and maturity. No single vendor has completeness to provide a private cloud and never going to be a single vendor in future, it is going be to combination several vendors. What I find very intriguing every single vendor thinks and implement own version of life cycle spin. The life cycle conflicts are serious issue. The life cycle conflict ranges from enterprise’s vision or practice vs IaaS vendor(s) vs Life cycle management vendor surrounding IaaS vs PaaS .
If you noticed several industry pundits’s predictions 2011 (Yes predictions become a mainstream these days) – “enterprises try to implement private cloud and fail….” Apart from cost and skills issues, life cycle conflicts one of many reason “ideal” state of private cloud looks difficult to achieve.
Most public cloud offerings are at IaaS level. The life cycle management issues still exist with IaaS + PaaS in public cloud, the only difference in public cloud, you are on your own with respect to the life cycle of PaaS. Few things to consider when focusing on private cloud initiative
- Have clear separations of concerns between IaaS and PaaS layer in the life cycle
- Design the provisioning of VM to support fine grain level with respect to various state of life cycle
- Spend time on naming convention for VM instance and educate the audience
- Choose the supporting product that complements your enterprise vision of private cloud and its life cycle
Side notes on 2011 predictions: Out of all the predictions that I read, my favorite one is JWT: 100 Things to Watch in 2011 (thanks for the pointer Fred Wilson)
The JVM has not leaped with cloud hype. Let me explain what I mean. Each JVM (application server or home grown or java process) has it is heap size min and max. The heap size cannot be changed once the JVM started; only way to take advantage of more heap size is to restart the JVM with adjusted heap. The cloud promise of elasticity, dynamic usage of resources, fast & efficient provisioning has not changed anything with characteristics of JVM. With respect to provisioning of application into JVM you have only two choices either add the new application to existing running JVM or start new one. Choice over one vs. other is depends on the startup time requirements (such how fast you want). Generally starting App in an existing running JVM faster than the starting new JVM. Most application servers such as – Jboss, WebLogic, and WebSphere does a nice job starting new app without restarting the application server. Even without starting the application server you still have the startup time for the application.
When designing the provisioning policy for new JVM based on the workload demand, you need make sure that you caliber the startup time. Ok, how you caliber the startup time with provisioning policy. Everything is boiling down to the rate of request into the system vs your startup time. You can define the policy easily. In order for the policy to function properly, there is need for a very well integrated provisioning system which has ability to collect data at the edge and dynamically adjust the policy vs JVM capacity. Unfortunately I have not come across solid integrated provisioning software as whole in this context. What this means , for a mission critical application you need little bit conservative on your capacity of JVM that can trigger new JVM –i.e when you reach 60% of JVM capacity wrt user request it is better spawn off new JVM. In other words you really do not want allow the user request to bring down the system. These are all good when the rate of request is steady and predictable. So put lot of thought process on your mission critical applications – resource sharing less important than the failures…
Side note: In Oracle (aka Sun JDK) JDK the PermGen failure is fatal. When you hit a out of memory due PermGen space the JVM unusable, requires restart with adjusted PermGen space. If you are provisioning an application to existing application server, then you need to carefully scale the Permgen space otherwise you end OOM on PermGen. For more details on PermGen read the Frank Kieviet famous PermGen blog.
Every application in the enterprise have life cycle of development, testing and production at macro level and life cycle is no different in cloud at macro level, but the micro level details at the each level might change depends on the choices.
As you know, one of the key promises from Cloud Computing is faster provisioning of services with transparency. This promise dramatically change the way enterprise used to operate in the dev-test-prod life cycle. Again it all depends on the choices. With respect to dev-test-prod life cycle there might be few possible cloud topologies.
- No physical isolation between dev-test-prod - Logical isolation – All in one
- Physical isolation between dev-test-prod – Physical isolation – separate
- Development at Private or Public Cloud, Test at Public Cloud and Prod at Private Cloud – Hybrid
Each one of them has its own pros and cons. It would be impossible to cover all pros and cons in single post, but I try to cover few of those.
All in one:
In this model, you will have no physical isolation between the development, test and production. In the pooled resources of all cloud layers available for development, test and production. This model has high scope of realizing cloud benefits both cost and other benefits. In order to operate in this model, enterprise skills, process and governance model has to be highly matured. Otherwise there would be lot of risk associated with this model. Most issues in the cloud environment is / going to be human error. The number # 1 issue is security. The productions resources & layers to have to be logically isolated and has to be designed & implemented with all the security imperatives in this context. Since all the resources are in same pool, the provisioning policies built in such way they should be affect production demands or needs and this requires thoughtful designing of polices. This is not an easy task, requires good governance model in the enterprise.
Separate:
In this model, you will have physical isolation between development, test and production. This is most obvious choices for most enterprise, since the enterprise used to this model in their current process. Also it provides nice transition from the current model to cloud. But the cloud benefits realizations are low and low risk when compared previous one especially when an enterprise lacks skills and governance model. Also to the enterprise that have “follow the sun – 24/7” model, then development and test clouds utilized to the optimal level.
Hybrid:
In this model, enterprise operates with combination of private and public model for development, test and production. However the combination of development and test, but the production is at private cloud. Testing at public cloud provides some level of cost savings and several enterprises already realized the cost benefits. When running performance or endurance (Stress) test in cloud there is a huge cost savings in term of both physical assets and testing software perspective. If you have not looked at the tools like – SOASTA, Load Storm, you may want look at cloud testing tools segment.
Most enterprise is looking into or in the process building a private cloud. Each cloud vendor is pitching the value propositions of the private cloud. In the nutshell, the value propositions are scalable, flexible, faster provisioning of services with transparency, high performance, cost effectively meet the IT requirement, dynamically respond to change & demand and reduce overall capital expenditures. If you notice the value propositions, several of them are meeting dynamic needs. The efficiency of provisioning so high in cloud paradigm compared traditional data center. But the provisioning solves one of the several issues. Several of the enterprise tends to approach the bottom up approach – i.e builds the private cloud first. You can realize certain value in the bottom up approach. In order to realize full value the private cloud approach needs to be looked at both top down as well as bottom up. To realize the private cloud values the enterprise collectively need to get good understanding as well redefine certain aspects. These aspects are (not an exhaustive list, but minimal need to be looked before jumping into the private cloud built out) – Application Portfolio rationalization, Application Workload Characterization, Application Life Cycle (define what it means in the private cloud), governance model mostly in the context of application life cycle in the private cloud. In this post we look into Application Portfolio rationalization & e work load characterizations and in the subsequent post we will look into the application life cycle and governance model.
Any portfolio rationalization involves classification of assets into categories with respect to cost & value. Application portfolio rationalization is huge effort. Basically categorizing the enterprise applications based on cost, value, strategic and non-strategic. If you already gone through the heat maps with respect strategic vs non-strategic business and its respective line of business applications then you regroup them into low cost-low value, low cost-high value, high cost – low value and high-cost-high value. Otherwise you have to do both heat maps and cost-value mapping. Regardless of the private cloud effort, enterprise has to do the application portfolio rationalization effort periodically. When you are building the private cloud, each one of the application group are good candidates and provides / dictates the requirements for the private cloud.
Similarly you need to know the application workloads and ideally you should define the workload characterizations each groups that you defined earlier in the rationalization. The workload characterization is critical piece with respect to cloud. The workloads variation differs from application to application and its line of business. As I mentioned earlier you got to know all the breaking points. There are two types of workload spikes – predictable and non-predictable. The predictable ones are the line of business knows / has historical data to determine workload characteristics. The non-predictable one based on both internal and external events which line of business does not previous knowledge. The whole idea of knowing the workload characteristics is mainly to get the fine grained set of policies to drive provisioning. Without the set of polices, it would be impossible to meet the dynamic demand and change that private (cloud) promises. The fine tuning of policies are on-going process in an enterprise. The predictable workload spikes are easy to manage and non-predictable ones require thoughtful policy definition.
The certain type of demands can be easily meet by private cloud provisioning itself and certain type of dynamic demands or needs cannot be achieved through optimally by provisioning model. These exceptions workload has to be handled specially at the middleware or application level. Again this varies application workloads to workloads. So it is critical for enterprise to understand these workloads and patterns in order to realize the private cloud values.
The key take away is – as part of private cloud effort, you need to look both bottom-up as well as top-down.
Last few weeks I did not have breathing room for blog post and I realized that this post sitting in my hard drive for long time. Here it comes..
For most business, flexibility in business will be more important than operational efficiency. The flexibility in business comes from the agility of its business process (hey I am talking about Business Process, not the other software vendor defined one). An enterprise has two categories of business process – Strategic or non-strategic. Most non-strategic ones were either outsourced or enterprise looking for a way to reduce its cost such as SaaS. Not all SaaS solutions fall under non-strategic side.
The strategic business process is critical for a business; most enterprise would like to have more control over the strategic business processes. If you look at SaaS vendor offerings in in the industry right now, they look like silos (Silos are -Structured Function Oriented monolithic architecture) in most cases (There are few exceptions) and more appealing to the end user (mostly towards a human interaction) rather than an enterprise business process. Most SaaS vendors think they are the center of universe and hold the gravity – i.e. less or no integration points. There is plenty of evidence why they are silos – if you look at the pricing of most vendors are based subscription based usage (direct emphasis on human interaction) and very few of them offer transaction based.
Whether you know or not Business is event driven and systems are transaction driven. The continuous binding between event vs transactions are the whole existence of the Software, Hardware, IT – now Cloud, SaaS, *aaS. The agility in the business process is integral binding factor between the event based and transaction based.
When there is less or no integration points for non-human (system) then you simply losing the opportunity to participate in enterprise business processes. For any software, services / consulting revenues depends on the integration points and ability to participate the enterprise business process. The critical successful factor of any traditional software comes from its consulting / services and support. Not the consulting like the below one…
The integration opportunities is not going away however the delivery model. If look at the large system integrators, they are not at all worried about the cloud, SaaS or any *aaS. In fact they have huge opportunities around the new delivery model.
In traditional on-premise model there are several protocols & API choice for the integration such as HTTP(S), JMS, SOAP over HTTP, SOAP over JMS, JDBC and more. In the case of SaaS, HTTP or HTTPS protocol with industry standards data interchange format would be easiest choice. Providing integration points on higher order of services would be a high value to enterprise business process. Providing non-human integration points provides value to enterprise business process as well as provides opportunities further up-sell .
In SaaS Security there are many security concerns; one of the top concerns is identity management. Already most enterprise suffers from security silos – multiple identities with in their infrastructure. Most of the enterprise has existing identity management solutions in place or in the process making it one. In most SMB market segment organizations the identity management solutions are non-existent. The enterprise identity management is a huge topic. Disclaimer Context: The intent of the post is to focus on certain aspects identity management with respect to SaaS (mainly from large enterprise perspective not from SMB) and quick reminder “No such thing as absolute security”.
In SaaS environment three possible user management exist –
• SaaS provider managed user management
• Third Party managed user management – Security as a Service external to enterprise & SaaS provider
• Security as a Service with in enterprise – Most enterprise (large) one might have one or more way to do it.
When it comes to identity management issues there are there large key issues exist with respect to SaaS.
• Provisioning new users
• Managing Users
• De-provisioning users
Each one of the three user management scenario has its own pros & cons with respect to the three key issues. Both SaaS provider managed and Enterprise managed are common ones. The third party managed – i.e Security as a Service from third party is at the early stages of its growth. In the current market most SaaS consumer usage is kind of silo interaction. For example if you subscribed to multiple SaaS solutions for various needs, the interaction pattern are silo at that moment. The integration requirements will push SaaS Consumer and vendor to interact with one another. When that market shift happens you will see shift in the market where integration vendors will introduce new term – Cloud Service Bus or Cloud Service Brokers (Same enterprise bus concept, but at the macro level – brokerage model). In longer term, for an enterprise it would be difficult to deal each SaaS vendor separately and enterprise tend look for consolidated SaaS vendor offerings which can be provided some kind of brokerage model. These shifts are sweet spot for third party security as service.
When a SaaS provider manages user management, you (enterprise) have to explicitly handle the life cycle of identity both in the enterprise as well as SaaS provider side. It is not easy when you deal with multiple SaaS vendors, it would be identity management nightmare. The SPML provisioning is far from reality and there is plenty of evidence here … Similarly home grown provisioning (with SPML) might better fit within the enterprise boundary and not good fit with SaaS vendors. When you explicitly manage users at SaaS provider side, you are basically adding more identity management nightmares to your plates. In the SaaS, any de- provisioning workflow has to be immediate. When you deal with multiple SaaS vendors and adopting their user management explicitly, then user management becomes a distributed silo.
For these issues, if you are enterprise where you have existing security infrastructure you want to leverage those. In other words, you manage authentication at your (enterprise) infrastructure and send token (Claim – Claims-based identity isn’t new. It’s been in use for almost a decade) to all out bound calls – SaaS providers. The SaaS provider security system establishes the trust with respect to the token and token contains Authorization information for downstream Authz calls.
With respect to token standards – OpenID, SAML, WS-* are promising ones, each of these differs in approach, so the dependency infrastructure changes with respect to the standard. Based on the industry data, SAML has lots of traction and would be right direction given the frame of reference. For an enterprise, it is critical to consider user management & authentication within the enterprise boundary and token based interaction with SaaS vendor. By doing so, you eventually have good control over the life cycle of identity in the context of SaaS. In case if your enterprise lacks the security infrastructure to handle token generation then this would be number 1 item you need look at it before jump into the SaaS band wagon.
Release engineering requires different type of approach when it comes to SaaS. Traditionally those who delivered as on-premise model will have many difficulties. One of them would be release engineering. Most software vendor (large) release engineering highly streamlined (highly process driven). This is mainly due to the reason of minimize the risks in their release engineering process. The new software delivery model – SaaS is one of the key business change event. For any key business change event you always have overlap with existing and new. Currently the SaaS is in those overlap stage. This reminds me the S curve (Sigmoid curve); represent most of the business transition from startup to maturity. Any major changes in business model will spawn of “S” curve with its own transition. From traditional on-premise software vendor perspective they would like to pick new market – white spaces and keep their transaction revenue either through on-premise or SaaS.
Most of those software vendors will choose to deliver both on-premise and SaaS during overlap period. The SaaS offering might have few changes compare to on-premise. It would be difficult for a business to choose one vs. other during the overlap stage (see S Curve). Nobody knows how long the overlap period is, markets demands and dynamics determines how long it will be. Generally speaking software vendor those who delivered on-premise most likely deliver both on-premise and SaaS.
In my opinion there are lots of advantages for software vendor those who deliver both on-premise and SaaS. They offer unique value proposition of transition from one to another. You might ask – what is the need for a transition? There are many drivers for transition– Enterprise maturity, satisfaction issues, control, etc… There are lots of examples where customer moved from SaaS to their own private cloud and vice versa. If I were a customer, my bill of rights includes transition + Ray Wang’s bill of rights.
Back to the release engineering, when you deliver both on-premise and SaaS, the release engineering of SaaS should complement on-premise release engineering. There should not be battle. If you treat two different release engineering process no real correlation in-between, then you will be simply inviting the disaster.
For both SaaS and on-premise you have functional and non-functional requirements. The dimension of non-functional requirements in SaaS is different. There are several ways to achieve the optimal efficiency in the release engineering. Here are few thoughts …
In SaaS, you are dealing with homogenous and heterogeneous in the case of on-premise. In on-premise you have multiple version of software, multiple vendors, multiple OS to support. The testing effort is the largest chunk of the work with variations and combinations. You want keep your SaaS release engineering complements the on-premise. For SaaS you have homogenous platform – single middleware, database, OS. Keep SaaS platform as reference platform; funnel all your functional & non-functional requirements flow (develop and testing) through the reference platform.
Divide the feature into groups of the features; map those groups into SaaS release cycle. Ideally speaking map the sprint into a SaaS release cycle. This drives iterative development and release. Generally speaking if functional & nonfunctional requirements pass through the reference platform, over 75% issues discovered and addressed. Remaining issues are related to interoperability between the versions, vendor and OS. If you already delivered on-premise software you might know those interoperability issues and its pattern with respect to your environment combinations. Below picture is an attempt show the interaction between the sprints with respect to SaaS and On-premise.
In the scalability world, you either have a choice of vertically scaling (scale up) or horizontally scaling (scale out). In case if you missed Nati’s blog on Scale in and scale out you may want to take a look at it.
Whether you scale out or scale in, you have ultimate breaking pointing depends bottlenecks. The bottlenecks can vary and mostly depends on the nature of application architecture & its usage pattern. When you have resource bottlenecks (such as CPU, memory, etc – horse power) you can easily add to your existing infrastructure topology – various technology & product sets in place to address this issue. The cloud promise is exactly around this concept. Based on your demand infrastructure topology is elastic in nature, in order to accommodate more horse power to address the demand. If you look at deeply the “demand” is direct result of bottleneck. The bottleneck is the key influencer for demand. Your cloud environment is elastic in nature expand exponentially , but it cannot be elastic to infinite. Certainly you have a breaking point. This type of breaking point (soft) is somewhat good in nature.
But your application architecture and workload characteristics introduce other bottlenecks. If you have bottlenecks at the application layer – process level (not rehearsed best practices), then bottlenecks quickly bring down the exponential curve. Cloud (do not ask me to define the cloud – it is blind men and elephant story, certain things you cannot define – SOA, BPM, Cloud, SaaS…. Instead of arguing, take context driven meaning, lot of things in life requires context driven… do not want to get sidetracked here
, hope you get my intended meaning) might help certain extent, you have a hard breaking point. Similarly if you have bottlenecks at the data or data access layer, then it can bring down the exponential curve faster than the application – process level one.
The point is, there are several ways (methodology) to implement your optimal (closer to ideal) infrastructure topologies, but you got to know your breaking points.
In the case of on-premise software model, you do not need to know all combination of breaking points; you have comfort of taking certain risks. In on-premise software, you can simply run system against defined workload, measure, innovate, and repeat. Benchmark the standardize workloads, lead to competition, evaluate alternatives; turns debates into numbers. You may not have that luxury of taking risks in the SaaS. Most high availability architecture assumptions might fail in reality. It is impossible to prevent all the failures, but you can certainly build most tolerant system where system copes with failure (Nati’s phrase) provided the application architecture and implementations complements “most tolerant system” goal.
Ideally speaking you got to know all the breaking points, but knowing all them up front may not be possible, but as part of (SaaS) journey you should able to learn, adjust and refactor.
There are two types of Breaking points – System Driven or Process (more human). A good test methodology exercise both system and process. At least you got to know the system breakpoints. In SaaS, when disaster happens you are not only affecting your business, you are affecting many others.
The organization knowledge base, sharing, organization culture, experience, testing methodologies, workload characterization, etc… Influence your insights on breaking points. If you know more about your breaking points, you are eventually complementing to have a good Mean Time between Failures (MTBF). MTBF is not just system, more than that – it involves technical support organization, incident management team and many more. In SaaS – MTBF influential factors are based on the organizational strength, culture and System Insights. MTBF is huge topic, reserved for future blog.
Side Note: The Blind Men and the Elephant analogy has deep roots in Silk Road, the story has several tale and versions long before B.C. “The Blind Men and the Elephant” Poem by John Godfrey Saxe was one of the famous one in 19th century.
Thanks
Chandran
