Emerging role of PaaS (Platform as a service) in building cloud-native applications

Challenges & opportunities for cloud-native applications

Current technology landscape for cloud-native apps is evolving and Platform-as-a-Service (PaaS) solutions are constantly changing to meet the demands such architecture. As customers need flexibility and openness in terms of choosing PaaS solution (without any vendor or technology lock-in), a key need is to provide a neutral view in terms of:

• Which PaaS solution is the right fit for my enterprise (considering unique opportunities and challenges in each enterprise)?
• How does it help in realizing the vision of migrating toward cloud-native apps (with microservices as an architectural style of business services)?

The overarching problem of choosing the right technology solution & partner towards enterprise-level cloud-native apps creates an opportunity for all of us to innovate, build and implement the right-fit solution in a progressive manner.

Capabilities of Platform as a service for cloud-native applications

A reference architecture outlined below denotes the key set of capabilities required for building cloud-native apps and helps in choosing the right platform offering these capabilities:

Key platform as a service (PaaS) solution options

CloudFoundry & Kubernetes are great initiatives towards standardization of PaaS solutions but the consensus towards a standardized approach towards PaaS is still in an early stage.

Considering current market landscape with both serverless and other emerging trends, current PaaS solutions can be visualized as below (there are many variations coming out of options shown here by different vendors):

Conclusion

Cloud-native apps development is an evolving field and considering the novelty of the solution, industry players and standards bodies (such as IEEE) are still firming up standards and best practices. As there is no silver bullet in choosing any solution and enterprise context, governance and required capabilities drive the recommended platform as a service (PaaS) solution in supporting cloud-native applications. 

Disclaimer:
All data and information provided on this site is for informational purposes only. This site makes no representations as to accuracy, completeness, correctness, suitability, or validity of any information on this site and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use. All information is provided on an as-is basis.This is a personal weblog. The opinions expressed here represent my own and not those of my employer or any other organization.

NGINX | Big leap towards cloud-native application platform from a high-performance web-server

NGINX has recently (Sep 6-8) organized NGINX Conference 2017 in Portland (OR) and would like to highlight some of the key announcements made by NGINX experts in this blog. There is a paradigm shift by NGINX in recent years of offering a comprehensive application platform for Cloud-native Microservices not just a high-performance web server and the same message has been consistently delivered in this conference.

NGINX CTO (Igor Sysoev) announced their aggressive strategy to move beyond web server and offer a unique application platform for cloud-native microservice application platform with the same level of high performance. Also, it is supported by almost all major cloud vendors in the market today - AWS, Azure, OpenShift, GCP, etc.

As per w3tech figures, NGINX is now #1 web-server for 1 million busiest sites in the world. NGINX has achieved this only 5 years and it is a great achievement for opensource community.

Also, a lightweight technology like NGINX to support challenging demands of Microservices (such as monitoring, high performance, hot deployment, lightweight containers, less/zero maintenance, etc.) has been highlighted and a similar approach will be extended to the new application platform.

The overall application platform has 3 key components:

1. NGINX Controller

• Security using RBAC (load balancing config by app owners, self-control).
• Centralized traffic management (routing, push button LB addition, upstream servers management, SSL keys management).
• Centralized monitoring (application metrics, requests per sec, bandwidth usage, consolidated dashboard).

2. NGINX Unit

• A brand new lightweight open-source application server.
• Unique in the industry to support multiple languages in one application server.
• Current beta version supports Python, PHP & Go. Java & NodeJs support to be available soon.

3. NGINX/NGINX Plus Web Server

• High-performance web server, which is the backbone of the entire application platform.

In conclusion, big aspirations by NGINX as a company to move forward aggressively towards establishing themselves as a cloud-native platform. Keep watching NGINX!!

References:

• NGINX Application Platform - https://www.nginx.com/blog/introducing-nginx-application-platform
• NGINX Unit - https://www.nginx.com/products/nginx-unit/

Why In-memory computing plays an important role in Microservices Architecture?

Microservices is the new architecture paradigm everyone is talking about, but it comes with its own set of complexities. As our industry gets more matured about using Microservices architecture, one of the key learnings coming out as:

The outer architectural building blocks are playing far more important role than the inner architecture of each microservice itself.

I will be sharing my perspective on microservices' outer architectural building blocks (In-memory computing & caching, API Gateway, Containers, DevOps & Cloud Computing) in a series of upcoming blog posts. This blog post is focused on "in-memory computing technology", which plays an important role in microservices architecture.

In-memory computing, in itself, is a vast technology domain but in the context of microservices architecture, I would like to keep it focused on following solution offerings:

• In-memory database - a database system primarily residing in memory (SQL or NOSQL).
• In-memory data grid - distributed computing based caching system usually having KV (key-value) storage.

In-memory database (IMDB)

In-memory database plays a collaborative role in microservices architecture as usually it can be deployed independently and provides highly efficient storage support to microservices. 

Note that to sustain data stored in in-memory database during deployments, a backup approach with file-system based storage is required.

These are following key design patterns, which can be applied in the context of in-memory database:

• Pattern A - IMDB per microservice, where each microservice having its own storage
• Applicability: Greenfield development where you have opportunity to do microservices based architecture first
• Pros: Independent (inclusive of deployment flexibility) & completely in adherence to microservices principles
• Cons: Duplication of data across services
• Pattern B - IMDB as a shared component across multiple Microservices having common storage
• Applicability: Brownfield development where you are on a path to refactor monolith application to microservices
• Pros: Practical approach when you have shared data across services
• Cons: Not completely aligned with Microservices principles
• Pattern C - Hybrid of Pattern A or B (some microservices having shared database)

Microservices Architecture - In-memory database design patterns

In-memory data grid (IMDG)

In-memory data grid relies on distributed computing using clustering as underlying approach and provides a shared component (grid) for CRUD operations using memory.

As microservices architecture recommends independent deployable units with minimal shared data, in-memory data grid is not completely aligned to this architectural approach. However, in-memory grid products can provide independent cache nodes to respective microservice with variation of distributed cluster to store backup data in the grid.

In nutshell, conceptually these are different approaches:

• Microservices architecture - It promotes independence and less dependency for linear scalability (cluster of instances of microservice but clustering at layer level is not recommended).
• In-memory data grid - It relies on cluster of nodes (data layer) for horizontal scalability (nodes can be added/removed on need basis for scalability).

Because of the above reason, vendor like Oracle has started their cloud roadmap with less emphasis on Oracle Coherence for microservices architecture and more on cloud based offering for Cache-as-a-service, which can be easily integrated with microservices Architecture. However, this is also similar to common grid solution with variance that cloud is now playing the common grid. Also, In-memory grid solution is still relevant and playing its role behind the scenes (to support cloud's cache-as-a-service). 

From applicability perspective, following patterns can be leveraged for microservices architecture along with in-memory datagrid solution:

• Pattern A - In-memory data grid as event/messages store
• Applicability: Primarily for inter-microservice communication, this pattern can be leveraged.
• Pattern B - In-memory data grid as shared data
• Applicability: To store shared data such as backend system response (cached data), response data, content data, etc.
• Pattern C - In-memory data grid as storage
• Applicability: To store data in grid for a microservice and use partition approaches to separate data for each microservice

To conclude, in-memory computing plays a significant role for Microservices architecture as an underlying storage mechanism for each microservice. Also, in-memory grid computing offers an alternative solution, which respects microservice's principle of independence up to certain extent and provides a out-of-the-box solution to solve inter-communication & storage challenges for microservice architecture.

References: 

https://www.forrester.com/report/The+Forrester+Wave+Big+Data+NoSQL+Q3+2016/-/E-RES125643

https://www.gartner.com/doc/3467318/magic-quadrant-operational-database-management

https://en.wikipedia.org/wiki/List_of_in-memory_databases

-->

 In-memory database & In-memory data grid solutions

In-memory database & In-memory data-grid solutions