Sorry, you need to enable JavaScript to visit this website.

Cloud Native Solutions: Bringing Application and Platform Architects Together

Cloud Native Solutions: Bringing Application and Platform Architects Together
December 19, 2017

Unprecedented changes in the current IT landscape and fast adoption of public and private Cloud pose real challenges to two widely different but connected IT communities—

platform architects and application aArchitects. Further, inadequate understanding of each other’s domain results in inconsistent application solutions deprived of real Cloud value. Here, we try to highlight different perspectives for the two domain architects to focus on common problems.

Defining application and platform designs

While application design focuses on designing applications to achieve the business outcome, platform design focuses on nonfunctional aspects to provide a supporting environment. Platform design focuses on services to host and run the application in an optimal way and respond to application design demands.

The clash between service usage designs in applications becomes a cause of confusion, resulting in developers not fully utilizing platform capabilities in applications.

This leads to suboptimal application design, unpredictable performance, underutilized platform, and even failed implementation owing to inconsistent application behavior in Cloud-native solutions.

Design factors which need to be considered

So, what are the common design factors that need focus from both the worlds to avoid confusion while designing an application? Importantly, design for future demands some space for backward compatibility and the ability to accommodate unforeseen future demands. Platform and application designers must ponder over several aspects that complement each other.

For application architects, it’s important to design an application that is self-healing and has a mechanism to detect errors or deadlocks. Applications being designed for cloud platforms or PaaS platforms can leverage platform features to build resilience. Platform design provides a scaling feature which initiates a new instance of handling crashed applications or deadlock situations.

What platform architects should do?

Platform architects are responsible for designing platform implementation with resilient design in mind, providing proper exposure of services to developers, educating them on usage, and enabling motioning for smooth behavior analysis.

While the platform will have various catch points to detect and act on application errors and failure notifications, the application needs to properly utilize them to communicate erroneous situations. Platform architects need to factor in future capacity demands in mind while creating a solution so that the application can release capacity seamlessly.

Points application architects should bear in mind

Application components can be instrumented to ensure internal runtime statistics is available to external tools for consumption. This data is used for application monitoring and application stack administration.

For example, Azure PaaS service provides application insight as platform feature for this purpose and Application Architects can put this as a design to use application insight SDK while developing application on Azure PaaS.

External configuration server is another platform that needs to be fully utilized by application architects. Keeping configurations helps in making changes as per business requirements without impacting applications in runtime. The PaaS Cloud model provides various provisions for log handling in real-time and one popular way is to channelize all logs to standard output as hosepipe and external log management service can easily plug in and start processing.

Platform and application architects work collaboratively

Applications, when redesigned in containers, are modeled to expose services and data as APIs. This is a de-facto way of converting functionality in the complete software module. Various application components in containers communicate through internal routing component of PaaS system. For example: In pivotal Cloud foundry, application components can communicate to each other if routing is enabled in the ‘GoRouter’ component.

All incoming traffic is managed through this component and a platform architect has the option to write custom policies per the application architecture. An application architect needs to ensure API monitoring is exposed to external systems for capturing and logging any possible API disconnect or failure situation. API ecosystem can be efficiently managed with specialized API management software.

PaaS comes to rescue

PaaS provides the right kind of runtime environment where the components can scale up or down as per the need

Software architects have used object-oriented designs for software designing. JAVA, for instance, offers robust support to modular application development. Hosting platforms were never designed to be scalable and did not get the full benefit of component-based design. Heavyweight application servers provided running environment but failed to expand with increasing load on certain components.

PaaS provided the right kind of runtime environment where a few components could scale up at a time and scale down when the load decreases. Application architects can try understanding the PaaS runtime platform architecture and this will help them gauge the mammoth effort required in breaking down a monolith application into small micro-service components and overhauling application architecture. This is the first step toward planning migration of the relatively old application to PaaS.

Avoid performance issues during scaling

Distributed applications deployed on Cloud should be designed to take care of latency and performance issues. Deployment of these cloud native applications can take place across geos if the underlying platform is configured.

Platform designers must keep in mind the applications deployment model and define the scaling policy for the container. For example, a pivotal Cloud foundry where Diego cells can be configured to scale up and scale down, based on an application that runs on these cells. Rebalancing of cells can create performance issues for applications during scaling as it is a processer-intensive job. Best way to deal with such situations is to jointly define the policy for a platform based on certain predictable future load on the application.

Effective measures which help avoid inconsistencies

Maintaining session state in containerized applications is very difficult and runtime crash of container can result in inconsistent application behavior. Cloud native applications should keep session data separate from the application in an external database to avoid this. Further, Creational patters are being used in software engineering since a long time and they become significantly important while designing cloud native applications. Singleton pattern is used to ensure we have only one instance with global access and this helps in preserving state which will otherwise create inconsistent functionality in the application.

Bringing architects across domains together

Once Cloud adoption becomes an integral part of the future vision, the next thing is to bring application architects and platform architects together for planning the strategy around quick Cloud adoption for legacy and new application development and deployment. Moving old applications to PaaS Cloud would need application re-platforming and certain components would need complete architecture overhaul to become Cloud-ready.

Platform architects can help bridge this gap by sharing necessary knowledge around platform flexibility, policy-driven design, and help avoid future conflicts in designs.