The path towards cloud-native applications is being adopted by more and more companies. For green-field applications this is a natural choice to architect your applications in a way so that they can be developed, deployed and operated in a cloud environment. This of course could mean on-prem, hybrid or public cloud.
When thinking about your heritage applications and your desire to modernize those, a cloud migration isn’t typically an easy thing to do. Not primarily because of technical reasons, but typically because they exist for a reason and in many cases these applications are mission-critical. Once you made a transformation decision and you created a business case, the next step is to come up with a suitable roadmap for the application. In a previous post, I described the major approaches of such a transformation. In my opinion there is only one suitable way if you truly want to leverage cloud-native concepts and make use of benefits from a cloud deployment … and that is a re-architecture.
Whether you follow a symmetrical or asymmetrical approach is dependent upon the application architecture and your enterprise architecture landscape. An important piece of the concept is to have the application artifacts represented in a platform independent model (PIM) so that you can then transform them into a platform specific implementation. The basic concept of having such an abstraction layer follows the Model Driven Architecture (MDA) approach. A great source of information for further reading can be found at a website led by Jordi Cabot named Modeling Languages.
So, the question is, how can we take what we have gathered in the PIM and re-architect it into something new? A great benefit of having all logic that makes up your application available in a platform independent model is that you can then use highly customizable templates to generate a new application architecture from the PIM. Out of the box, an MDA approach typically generates web applications with pre-built, standard target reference architectures like:
- Java (Hibernate, Spring, AngularJS)
- .NET (Entity Framework, Web API, AngularJS)
You can easily deploy these into a PaaS environment. For instance, the .NET solution can be deployed to an Azure App Service without modification. As another example, as recently mentioned, the Java solution can also be deployed to the SAP HANA Cloud Platform (HCP).
Just to prove the flexibility of such a templating engine, I also created some additional template packages for target platforms such as:
- Salesforce’s Force.com
- (Pivotal) Cloud Foundry
- future state application uses
- Spring Java configuration and bean profiles to configure the application and the connection objects needed to use the persistence stores
- Database services on Cloud Foundry: application stores the same domain objects in one of a variety of different persistence technologies – relational, document, and key-value stores
- Spring Framework and Spring Boot
- Spring Cloud Connectors library to inspect the environment when running on Cloud Foundry
- o application can be build using Gradle and deployed using Cloud Foundry’s native tools (CF command line interface CLI)
- future state application uses
These packages act as samples that can be leveraged to jumpstart your cloud development. All of these templates can be adjusted and adopted to your specific needs and requirements.
Of course, you can create these cloud apps by hand, but 1. we already harvested a lot of artifacts that already exist in the PIM, 2. manual per se increases effort and defect level, and 3. the re-usable aspect of templates created and adopted once and used multiple times.
Let me help you re-architect to the cloud. Contact me to get moving.