Cloud-Native

Attemt to clarify and demystify the term of Cloud-Native

As with many other IT terms, there is no clear and general accepted definition of Cloud-Native. The range on existing definitions is wide and usually depends on the publisher view and opinion. That makes it difficult to find an objective characterization. Here are my thoughts about the term Cloud-Native listed as theses.

In recent years, applications have found a new habitat at the Cloud and the borders of a dual view on the Enterprise IT - described as Bimodale IT (Gartner) or Two-Speed IT (MyKinsey) – became, over time, more and more blurred. The increased gravitational pull of the “Cloud” captures not only system of innovation or differentiation (aka mode 2), but nowadays also the traditional systems of record (aka mode 1). Then what do the people mean by saying that the real benefits of the Cloud will come with Cloud-Native applications? What precisely does the term Cloud-Native mean? Where does the term Cloud-Native actually come from? In which context is it appropriate to use the term Cloud-Native?

As mentioned above, there is no formal definition of Cloud-Native, but one can list and describe what we see as common characteristics that fit the label. My view comes from own multiyear experiences at well running and, in particular, under-performing Cloud projects. Often these experiences and the resulting conclusions are congruent with the opinion of esteemed professionals who are much smarter than I am.

 

Thesis 1: “Cloud-Native” at its core is about applications and their architecture

Cloud-Native applications are running on modern API driven elastic infrastructure, packaged and deployed through DevOps processes and CI/CD automation workflows (CI/CD stands for Continuous Integration, Continuous Delivery and Continuous Deployment in this context). I think that most people would agree with me that this seems to be the formula for success of today.

However, the focal point is about the application itself and their characteristic architecture, assembling cloud-based components in an optimized way for a cloud infrastructure. It is a change in architecture on how deviding things up as compared to the past (vague, I know).

Cloud-Native needs Cloud infrastructure. Nevertheless, Cloud infrastructure XaaS (X is variable) is a means and not an end in itself, like all the other “noisy things” from agile techniques to CIOps or latest GitOps. Agile development methodologies grounds evolved long before the cloud-thing was coming up. Even with the best agile process, project teams have build poor traditional applications in the past or supposed Cloud-Native application these days. Moreover, a very sophisticated deployment process with a high degree of automation could deploy Cloud inappropriate applications. Agile development and innovated CI/CD processes will guide the creation and deployment of Cloud-Native applications but are not the centrepieces. It even tends to be the opposite; Cloud-Native applications facilitate agility, are the base to enable often and fast independent deployments fully automated to all staging environments.

The real problems arise from weak architectures with poor modularity that often leads to a big ball of mud. Neither an unmanageable strong-coupled service mesh (also called Cloud-Native spaghetti) nor monolithic service blobs will give the stakeholder the outcome that they hoped for.

The final objective behind Cloud-Native is to minimize time to market by working fast on cloud-fitting applications delivering business value (speed factor). It is about speed to market by getting it right in a faster way. This requires an architecture that care about “putting things apart”, having distributed and discrete units with clearly defined service boundaries. Ideally build Cloud vendor-neutral and therefore able to run anywhere (freedom factor) with a 24/7 uptime facilitated by redundancy together with fast self-recovery (trust factor). “Cattle” infrastructure with supporting applications swiftly replacing “pets” (never heard of the "Cattle not Pets" paradigm of disposable server infrastructure, see the explanation of the expression creator). These applications are build with mature technologies and frameworks which are important but not Cloud-Native itself, it is the way they are used (= architectural and design pattern paired with best practices).

 

Thesis 2: “Cloud-Native” is the approach to build applications with services for Cloud environments from day one.

Cloud-Native applications have an inhärent Cloud-DNA, they are born in the cloud. “Native” is derived from the latin word “nativus" for “innate, produced by birth". It is about how applications are designed and built - not where they are deployed; the Cloud provider should not matter.
There are different Could-Native maturity models available (for example the models from HCL Technologies, JPMorgan Chase & Co. or Microsoft), they all have in common that Cloud-Native is the highest maturity level. Applications could climb the ladder up to be Cloud-Native. These matured applications must be built for the Cloud and – to be honest – it is a hard way to do it in the right way.
Therefore, simply deploying an existing legacy application in the Cloud does not make it Cloud-Native. Cloud-Native is certainly not a Lift-and-Shift approach (aka rehosting) to bring existing applications as-is from a local non-cloud environment to a new Cloud habitat. For some applications, it is possible to reap certain benefits of the Cloud going for a Lift-and-Shift or API-wrapped approach. In the end, both approaches give some time to refactor and rewrite the existing legacy applications towards a Cloud-Native application. Nevertheless, re-architecture and rewrite is the only way to update the application architecture as part of an overall modernization strategy – a rebirth as a Cloud-Native application.

 

Thesis 3: “Cloud-Native” build applications as Microservices, packaging each part into its own container and dynamically orchestrating those deployed containers in order to optimize resource utilization.

This thesis is the slightly modified original characterization taken from the Cloud Native Computing Foundation (CNCF) which is a non-profit technology consortium, created with the charter to define the term Cloud-Native and to promote cloud-based projects. All big Cloud players like Amazon AWS, Microsoft Azure and Google Cloud are CNCF members. There is no getting around CNCF, which gather heavyweights in the IT industry around one table to form a shared understanding. Today the definition changed to a more generic description, but the main message about the three original elements is still true in Cloud-Native reality: "application containerization; microservice-oriented architecture; application support container orchestration and scheduling".

Even though the characterization is a few years old, I still agree with the original CNCF characterization of Cloud-Native, especially with the wording “application as Microservices” which revive and reify thesis 2, claiming to “build applications with services” – clarifying that we are talking about Microservices.

Netflix is often regarded as one of the pioneers of the Microservice movement, shaping new Cloud architectures to operate at massive scale. There are many magic frameworks from NetflixOSS that help with fighting the distributed systems challenges. Adrian Cockcroft, the former VP of Cloud architecture at Netflix, was one of the first who used the term Cloud-Native together with Microservices:

Adrian Cockcroft: “The application is designed from the ground up to take advantage of the elasticity and automation provided by the cloud. It uses cloud-native patterns and practices, such as microservices, containers, and declarative APIs to achieve high availability, resiliency, and agility.”

I fully share that early days view, “designed from the ground” underlines addionally the significance of thesis 2, claiming for a cloud-day-one-architecture. Based on “cloud-native patterns and practices, such as microservices” is the reference to a Microservice architecture demaned at thesis 3.

Obviously, Microservices play an important role in the context of Cloud-Native. These two terms are closely interrelated. What are Microservices exactly? Although Microservices are also very broad and mixed defined, I would agree with the description given by James Lewis and Martin Fowler:

“In short, the Microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”

Previous theses and the given Microservice description goes all hand in hand. It is therefore clear to me, a Cloud-Native application – and Cloud-Native is first and foremost about applications - is build and deployed as a suite of small Microservices, each running as own process packaged as container. These small deployment units with one container per “bootiful” Microservice make fast independent deployments and individual scalability possible in the first place. The open success secret behind is to get the service boundaries right towards high cohesion internally and to be loosely coupled to each other (the best source to learn more about service boundaries is still Domain Driven Design).

In the words of Gary Olliffe, Research Vice President of Gartner:

“The superpowers of a Microservice architecture can, in large parts, be attributed to the benefits of loose coupling and decomposing systems into component services that can de developed, deployed, and operated independently of each other”.

Microservices should remain small to make them easier to understand, maintain, and to rewrite/replace (if necessary). In order to have a high cohesion, the service responsibility has to be right regarding the domain. Vaughn Vernon, a leading expert in Domain Driven Design, recommends expressly looking into Microservices when the rate of change across business domains differs substantially.

Once Microservices are packaged as containers, the second part of the thesis is about “dynamically orchestrating those deployed containers in order to optimize resource utilization”. I think, today we do not need any further discussion about the advantages of container orchestration and that Kubernetes (K8s) has won the game. Kubernetes makes containerized services radically easier to manage and became a key part of the container revolution. I would even go so far as to say that Kubernetes has become the established operating platform for Cloud-Native applications; it is the defacto standard Cloud-Native “operating system”. Nowadays a Cloud-Native application means also a Kubernetes-Native application.

Kubernetes became the standard for container orchestration because it allows you to treat your containers like Cattle. Meanwhile we treat the Kubernetes clusters like Cattle, too. Spinning them up and down on demand by using appropriate infrastructure as code (IaC) tools (Terraform is the most popular representative of this type of IaC tools).

 

Thesis 4: “Cloud-Native” is using an Open Source software stack

I initially removed the Open Source commitment from the original CNCF characterization in thesis 3 – in full knowledge of diverging views and to give it an own thesis. Is Cloud-Native associated with Open Source? I believe that is the case to a high degree.

Using a Closed Source provider who is most visible in advertising but not portale between Cloud platforms is not a good decision. Furthermore, a lazy decision for a software provider that have been used in a pre-cloud approach is also not a good decisionmaking base. Unfeasible auto provisioning, portability problems and exploding costs could be the result.

The usage of Open Source will enable freedom of choice. Using Amazon-/Microsoft-/Google-Source leads to a single Cloud vendor lockin. It is easy to yield to the temptation of the Cloud service providers using their proprietary services. But it is very difficult to outbreak when a move to another Cloud provider or a hybrid approach with multiple provider is suddenly on the agenda. It is also conceivable that a Cloud-Exit strategy is demanded in order to avoid becoming dependent on a single supplier, requiring a move to another Cloud vendor within a specific timeframe anytime in the future. Proprietary Cloud Source will create barriers to technology to pull into a particular Cloud; Open Source will eliminate barriers to technology to enable freedom of choice.

An AWS-, Azure- or GCP-first approach, using proprietary cloud vendor services make sense only in certain scenarios. One case might be the reason of lacking Cloud-Native architectural and Open Source tooling knowledge (combined with the need to speed-up the application development). Another reason is deep trust in a Cloud provider whatever may come. Nevertheless, an application design with a Cloud-Exit and migration strategy in mind offers more flexibility and avoids a Cloud lockin.

I believe that the crowdsourced wisdom of a highly motivated developer community will create outstanding software. Many developers coming from different directions, sharing experiences, let maturing software in public. CNCF promote trusted open source projects and give them a home. Just like in the real world where kids need stability to grow up, CNCF give stability and trust for the Clout-Native open source ecosystem. There is no particular endorsement of any one project over another. CNCF keeps the overview in a confusing tooling jungle and often providing the defacto toolset standard.

Dan Kohn, the the recently deceased former CNCF executive director, neatly summarized when Amazon AWS joining the CNCF as a platinum member in 2017: “Virtualization was the biggest trend in enterprise computing over the last decade. The age of virtualization is now ending and the cloud-native era has begun, with an open sources software stack enabling portability between public, private and hybrid clouds, with the addition of AWS today, all the major cloud vendors are working together supporting open-source development of cloud-native technologies, with Kubernetes a primary focus of their collaboration. We believe AWS' participation will help shape the future of enterprise computing."

CNCF claims to provide a collection of Open Source project anyone can trust in order to avoid that “cloud is eating open source” and running into a cloud-vendor lockin. They support common Open Source projects anyone can use on any cloud platform. CNCF is about working projects-first, they enable competition and choice. It takes very good reasons not to choose the CNCF Open Source toolset!

 

Thesis 5: “Cloud-Native” is only under strict conditions Serverless/FaaS

The innovative leap on Serverless or FaaS (Function as a Service) happened relative quickly after the Microservice revolution. Project teams still struggling to get Microservice architectures right and we already have FaaS around the corner. I use “FaaS” as a shorthand for the development of “server-side” logic written by application developer (in distinction from pure “glue code” between cloud-vendor specific managed services), but coming with certain limitations and constraints.

In my opinion, FaaS is not the correct approach for every problem (what we continually hear and read); it will definitely not replace all existing architectures. IMHO, the spectrum of applications appears to be more limited than using a K8s running Microservice approach.

FaaS comes with vendor specific quotas applied to function configuration, deployments, and executions. Typically, these quotas cannot be changed, there are restrictions! FaaS functions are typically limited in how long each invocation is allowed to run and how many memory could be used. Environment variables are limited, payload size is limited, code package deployment size is limited, etc. Additonally architects and developers have to deal with a FaaS cold-start latency, particularly unfortunate and inopportune when an interactive application has a need for quick response times.

Proponents argue that FaaS scaling is automatically managed, transparent and fine-grained, tied in with the automatic resource provisioning and allocation. But a K8s running application has also this autoscaling feature built in with Horizontal Pod Autoscaling (HPA) in a more custom metric controlled manner.

But what bothers me most is that vendor lockin factor which could be high if project teams are not careful. There is a high risk to get caught in a particular Cloud. But even when Open Source projects like the Serverless Framework or Spring Cloud Functions are used, someone could be trapped by other chunks of the vendor specific infrastructure. For example, an upfront vendor specific Gateway solution that is typically used for an API-oriented FaaS or a cloud-vendor managed GraphQL service to implement the FaaS binding. A changeover would become more than difficult; the vendor solution will not be able to run on anything else but the platform of choice.

One thing is for sure: the smaller the business functionality is, the more orchestration is needed. Yet another trap to get caught in a particular Cloud. Recently I was reading a tweet from Camille Fournier who expresses my thoughts: “I wonder if serverless services will become a thing like stored procedures, a good idea that quickly turns into massive technical debt”. In addition, there is another thing I am particularly concerned about: Observability (logs, metrics, traces) from a holistic perspective; rather difficult to establish good observability solutions with Mircoservices, muchmore difficult with FaaS.

In short, it may be that FaaS is a better choice for a short-lived and event-driven style having a few event types per application component that could tolerate occasional cold-latency delays. Whereas containers with Microservices are seen as a better choice for synchronous-request–driven components with many entry points (to share Mike Robers view). I am slightly surprised that we do not see more about an hybrid architectural approch on both styles – FaaS together with Microservices which might operate as FaaS aggregator.

 

Thesis 6: “Cloud-Native” applications need a Macro-Architecture

One might also wonder whether a “Cloud-Native” Microservice architecture perform miracles. Microservices are coming with the promises to be more simple to understand, faster to build, easier to maintain and simple rewrite/replace promises; more benefits are brought to bear because services are independently deployable and separately scalable (“unlimited” in the Cloud), reduced downtime through fault isolation, self-healing mechanism and service degradation techniques, etc.
But as mentioned by Gray Olliffe, it’s not the full story. The complexity removed from large monolithic applications by building simplified services has not gone away and it brings new challenges, and amplifies old ones. Most of the complexity gets pushed outside the Microservice.

Gray Olliffe: “That complexity has moved and, I would argue, increased. It now lives in what I call the outer architecture”

Microservices architectures are a tradeoff from inner complexity to outer complexity. Gartner calls it the Outer Architecture, other calls it a Macro Architecture in contrast to the Micro Architecture which addresses all internal Microservice matters (read also about the Independent Systems Architecture). The Macro Architecture is about architectural decisions affecting the entire system and is mostly the space between the Microservices. The Macro Architecture frees up the service teams to focus on just its own Microservice.

 

Thesis 7: Cloud-Native is NOT a big-bang approach and doing so will backfire incredibly hard

Cloud-Native architectures have plenty of challenges and are very different from traditional application-centric architectures. Just to name a few challenges: session management, database (schema) per service pattern, limited transactionality countering with the Saga pattern (“the art of undoing”), gateway pattern (“abstracting services”), etc.

A mindshift has to take place. Long-established truths have to be questioned and discarded (I am thinking, for example, about the DRY principle). It requires a change in thinking and that change cannot happen overnight. For example, we have long experiences working on architectures that try to operate fail-safe (MTTF focus), now we have to put the focus on fail-fast and recover quickly solutions (MTTR focus). Be aware and internalize the famous quote from AWS CTO, Werner Vogels: “Everything fails all the time”.

Also the technology flexibility for each service could turn into a mess when projects have gigantic technology stacks and services written in many difference languages. It takes time and a competent staff to handle such a flexibility and get it done right.

 

Conclusion:

I recently have read that Cloud-Native is about culture. That is too general for me; the term was born with a technical matter and not a fuzzy culture aspect. Often I see the term Cloud-Native hijacked by all kinds of Cloud aspects, just make it appear more interesting and meaningful. Cloud-Native is also much more than just another buzzword, it is a valuable term for applications build with an architecture fitting natively in the Cloud - as a result, it facilitates agility and maintainability. That is the quintessence. Cloud-Native is a technical and architectural matter – sometimes emotional, always intellectually discussed, difficult to grasp, hard and difficult to achieve.

SOA-Architecture - The future is the Any-Any-Any Architecture

Unchanged post republication dated 5/27/2013, still lot of truth in it

The Any-Any-Any Architecture (A4) is the consequence on current IT realities, new innovations and developments. I come across the term “Any-Any-Any Architecture” from a replay of a conference keynote from Anne Thomas Manes (VP&Distinguished Analyst, Gartner) on “New Paradigms for Application Architecture: from Applications to IT Services”. It means that applications could run on Any Device using Any Services working with Any Data sources. A4 must be deployable on the Cloud in order to have a faster time-to-market and to reduce costs by utilizing a uniform elastic platform.

In my opinion all signs increasingly pointing to an A4 direction because more and more smart connected devices running applications which request any services utilizing all kind of data sources. Modern interactive applications will be designed in the A4 architecture style.

The “application” is now on the device using a collaborative service mashup from different service-enabled backends. The application should work on Any Device with any resolution (and any up-to-date browser). The dominant model with server-side applications will change to client-side applications talking to server-side services running on premise and/or cloud. These services will use a variety of different data storage technologies for different kinds of data. Big Data will increasingly play an important role as the data volume will grow. NoSQL databases provide alternatives with better scalability and performance to the predominant relational databases. Martin Fowler is talking about Polyglot Persistence in this context. So polyglot implemented services which use Polyglot Persistence will become reality.

The change to Any Device happens today, whereas the change on Any Data is slow-moving because companies are naturally conservative when it comes to their data storage (to quote Martin Fowler). The change to Any Service should already have taken place.

Any Device

Mobile computing is actually the driving force on Any Device. Smartphones and tablets are pushing the mobility growth. Additionally new innovative devices like Google Glasses coming soon. Google Glasses belong to the device category of Wearable Computing Devices which are sharing the same challenges like mobile computing including the software architecture. All these connected devices need services to run applications. The service delivery of functionality and data has to be safe and guaranteed at any time.

Browser-based applications using HTML 5 with UI-centric JavaScript (JS) will succeed. Multi-page web application with a “Thick Server Architecture” are turning to Single-page Applications (SPA) with a “Thin Server Architecture” (TSA). jQuery is actually one of the most often used JS library. Newer touch-optimized libraries like jQuery Mobile will address the requirements of mobile devices. But there is a whole bunch of new JS libraries to enable Service-Oriented Front-End Architectures (SOFEA). SOFEA will expect RESTful Web Service interfaces.

I guess GWT and GWT-based products (like Vaadin) or JSF-frameworks (like Oracle ADF Mobile) will not win out over. JavaFX is pushed by Oracle and could also run on Android and iOS devices (demonstrated at JavaOne 2011). But will these technologies break the HTML 5 with JS hype?

Any Service

What’s about SOA? SOA is Any Service on an A4! Some IT practitioners think SOA is a buzzword that is history now. But in my opinion it’s the reverse case. SOA is definitely a pre-requisition of the A4 (to quote Anne Thomas Manes). Beside the reduced costs, monolithic environments with silo-based applications have not the agility and flexibility to serve multi-channel consumers (Desktop, Web, Mobile, Social, B2C, B2B and B2E).

The IT industry has mature technologies to build business-critical services running on fail-safe, scalable and highly available systems already today. One of the most promising solutions is the Service Component Architecture (SCA) which is an independent OASIS specification. Pure JEE Runtime Containers or the SpringSource Application Platform are also a reasonable alternatives. But in my opinion these solutions are looking pale compared with SCA supporting middleware suites. But a certain investment of time and cost is required to bring these middleware suite into Enterprise reality. 

SCA is a technology for creating services implemented and assembled as composites. SCA does not specify a presentation-tier or persistence technology, instead SCA has the focus on service implementation and integrate with other technologies. SCA Services itself may be implemented using different technologies and programming languages. Therefore you could add one more “Any” for Any Language of service implementation. Services are more and more polyglot developed. Multiple General-Purpose Languages (GPL) are mixed with multiple Domain-Specific Languages (DSL). As I already stated on my last blog, in order to produce polyglot implementations you need environments where polyglot-ism is encouraged.

SCA addresses the polyglot complexity and forces reuse. Therefore the SCA technology has strong supporters like TIBCO, IBM or Oracle. For example the Oracle SOA Suite 11g is based on a SCA polyglot supporting platform (including the SCA Spring components as part of the composites) and come along with an well-integrated ESB, BAM and CEP product.

Any Data

Data Services are Any Data. The dominance of relational database management system (RDBMS) will be broken in the future. NoSQL (Not only SQL) databases will become equal priority beside SQL databases. Different kind of databases like Neo4j as graph database, MongoDB as document-oriented database and Cassandra as distributed key-value database will become normality (just to name a few). Newer architectural pattern like CQRS (Command and Query Responsibility Segregation) will force the co-existence of SQL and NoSQL databases, because view data do not need to be placed on heavyweight SQL databases. In-memory technologies will also gain more and more importance and show us a way out of the “database is always the performance bottleneck” issue (“memory is the new disk, and disk will become the new tape”). Todays high-speed performance requirements need in-memory databases (IMDB) like Redis or SAP HANA and/or in-memory data grids (IMDG) like GemFire or Coherence. High data volumes on any type of data will be addressed by Big Data concepts (Volume, Velocity, Variety) and the de-facto standard open-source Hadoop computing framework. Even new integrity models with No ACID transactions and eventual consistency are coming up.

A4 One Step Closer

Let’s take a deeper look on the A4. What do we have today and how is it mapped on current technologies. Therefore I follow in essence the reasoning from Adrian Colyer (CTO Cloud Application Platform, VMWare) given on the SpringOne 2GX conference in 2012 (keynote: “The New Application Architectures”). In my opinion this excellent keynote confirms A4 in more detail.

The presentation layer logic implemented in terms of well-known MVC frameworks like Apache Struts will disappear from the server-side. The service layer is moving up and is now the front-line on the server-side (TSA/SOFEA principle). But the advantages of the MVC pattern are actually recovered by JavaScript developers in order to have the right level of abstraction and maintainable code structuring. JavaScript MVC frameworks taking control on the client device side.

Client developers could create also browser-based web applications which are able to run offline. Google Gears was the first step on client-side persistence and is now continued with the standardized W3C Web Storage specification. Web Storage (also called DOM Storage) supports durable local and temporary session storage.

The server will also be able to initiate the communication to the client. Server-side asynchronous events and notifications are pushed to the client. The W3C WebSocket API specification enables a durable two-way TCP communication between clients and the server. WebSocket support a reliable “real-time” communication with minimal latency.

Today we have several JavaScript libraries which are used in conjunction to do DOM manipulation, templating, modular loading, UI component handling, MVC structuring, etc. So AnyDevice development will come at a cost - but it will come because the benefits are worth it.

Business domain services will provide functionality and data through RESTful APIs. Private service-to-service communication will still use “SOAP over HTTP” Web Services or other binding types (like JMS, RMI or Socket). But lightweight REST Web Service communication to the client device has become accepted and prevailed in web-oriented architectures. Most common REST will return JSON or XML.

“SOA Products” offered by mature middleware suites like TIBCO ActiveMatrix BusinessWorks or Oracle BPM/SOA Suite will help to build Any Service connectable to Any Device. These suites absorb already a lot of complexity coming with SOA, but these products are not sufficient to “do SOA”. Finally SOA implementation needs an own practical architecture approach. As already mentioned, SCA technology will help to build business domain services, but an own “internal” design is necessary. And in my opinion this design is not platform agnostic. So you will need a more platform-specific idiomatic design, based on the selected middleware product. 

Access on Any Data will happen on SQL and NoSQL databases, not forgetting Content Repositories. The most common ORM tools already support NoSQL databases (like Hibernate OGM and EclipseLink NoSQL). But also other forms and types of persistence stores like HDFS (Hadoop Distributed File System) are expected to become increasingly the standard case.

More and more solutions will move towards a Cloud platform because of a budget dilemma and time-to-market considerations. On Hybrid Clouds parts of the solution are running on a hosted Private Cloud and parts on the Public Cloud. Hybrid Clouds will appear as a usually solution in the future. Sensitive services on-premise, others on shared and rented off-premises solutions. So fluid IT boundaries turn to reality.

Application services should be deployable to wherever it is optimal (a decision mainly based on security and compliance concerns of mission-critical solutions). PaaS Clouds will play an important role on the application journey to the Cloud. PaaS is about Middleware running safeguarded on-premises or on the off-site Cloud. In my opinion it is desirable to choose a PaaS Cloud solution where application services could work without modification on both, on-site and off-site at a Cloud provider. 

For example Oracle provides a Virtual Assembly Builder (OVAB) (as part of the Cloud Application Foundation 12c) which capture the application topology and virtualizes from the environment. Afterwards the deployment could happen on conventional or engineered systems, but also on hosted Private or Public Clouds. So on-premises and off-site (remote) solutions are supported equally. BPM and SOA Suite developed services could benefit, but also pure Java solutions would be deployable on Oracle MWaaS-enabled Weblogic application servers (MWaas = Middleware-as-a-Service).

Conclusion

The A4 objective is to create solutions, allowing your company or organization to be innovative and competitive (by keeping the in-time, budget and quality constraints).

Gartner warned already last year: “Applications created in 2012 using traditional architecture models will be an IT-constraining legacy by 2016”. Jeff Bezos (Chairman and CEO of Amazon) realized quick the benefits of a Service-Oriented Architecture already 10 years ago. Therefore he formalized simple rules to transform Amazon internally to a SOA. Data and functionality has to be exposed through service interfaces which are the only way of communication. A4 also highly demands independent and autonomous components. Client-side applications must be decoupled from services and data. Companies and organizations without a SOA approach have to realize that it’s late, but the longer they wait, the closer they get to being Too Late.  

Healthy companies or organizations always seek to improve their ability to create software and general conditions that meets their needs at reasonable cost. A4 provides competitive advantages, so think about what A4 means for your company or organization.