The Enterprise Application Architecture (The cloud)

• Migration of Applications
• Managing Risk for Legal, Regulatory and Business
• Meeting the SLAs as defined by the organization
• Managing Cloud Applications
• Total Cost of Ownership

While these are all noted as being impediments, they can all be overcome and to some the value gained greatly outweighs the potential risks associated with a move to the cloud. The cloud offers an intrinsic gain of speed to market, fungible infrastructure and end to end encryption for heightened security.

The nature of an enterprises application architecture is fundamentally changed by the introduction of the cloud, however I feel this is for the benefit of the organization. Tacking the articles impediment of application migration, the architect needs to consider a few things and change the assumptions they are accustom. Not all applications will be “lift and shift” into the cloud. This is a traditional methodology for moving applications into a new datacenter location. The architect should reassess the applications one by one to evaluate their likelihood of survival in the cloud. Most applications as-is will not be able to migrated to the cloud, however they can be re-engineered for the cloud. Doing this takes advantages of cloud-specific mechanisms like auto-scaling and out-of-region replication that normally would take specialized hardware and software to accomplish. Another consideration the architect should be cognizant of is licensing. Make sure you tell you cots vendors that the cloud is where you want to be. They often have antiquated licensing schemas that make it cost prohibitive to operate in the cloud. Remember, this is a negotiation that an architect is suited for when working with a vendor.

The next portion of this is management of Risk in the cloud. This is a story I deal with often and the root of it lays a the feet of the lift and shift mentality. When reengineering an application the architect needs to keep in mind the Risk is no greater than in your own datacenters, however by refactoring or provisioning encapsulated infrastructure you can encrypt your data at rest and in-motion as well as isolating the cloud footprint at both the network and hardware layers (if you’re truly worried about tennecy). Another mitigant of risk in the cloud is the ability to deploy and manage the footprint on-the-fly, such as services offered by cloud providers (ie. CloudFormation). Finally another technology like containerism is also a technology that has been present for a while but together with the cloud makes products like Docker much more attractive and together facilitate overlooking some of the shortcomings with on-prem usage of containers.

Architects will need to manage the organizational perceptions of the SLA. This certainly slows the adoption of the cloud but is another impediment that is removed. Concerns associated with downtime is mainly linked to the hardware in which the cloud ride on and that the providers will not offer SLAs. While this is true, they often have their own SLAs that they use to manage the infrastructure. It is up to the business and business continuity teams to ensure critical workloads are maintained as such. Major providers offer various physical locations whereas the risk can be mitigated, but unfortunately similarly to on-prem replication there is a cost associated with those critical workloads.

The cost of ownership is a final parting shot at the case against the cloud. Pound for Pound, I agree with the article, cloud computing doesn’t provide any gain against cost. On a cursory glance, it does but as you add in the resilience, recoverability and footprint needed to operate in the cloud, we see that cost is not a compelling argument. What the cloud does allow you to do is save money based on the fungibility of infrastructure. Your capital expenses become nil and in models like Dev-Ops where infrastructure is part of your deployment, you can remove overhead associated with peak times, upgrades, patching and other operational cost centers. Your development teams can turn stuff off and fire it up when needed. Additionally cloud computing (google and amazon) are moving to what they call serverless models. These services only charge for your compute and storage when you use them. So there is no idle time, only high density operations that are on-demand.

In conclusion, the article highlights many of the reasons the sentiment is apprehensive moving to the cloud but in contrast the cloud offers many new and exciting ways of transforming computing and opens up a new playground for the application architect. Managing application and their interoperability in the cloud and back on-prem pose those new challenges. Topics like vendor lock-in, technology interoperability, business continuity and portability will define the role of an application architect going forward as cloud adoption becomes more prevalent.