Auto-scaled Business Logic Using Declarative APIs and Microservices in Clouds vs Legacy IT

1.0 Introduction

Today the intent to use open source, open API and run time portability is fulfilled by ensuring declarative APIs and Microservices work together to get the most out of the runtime code as the framework of monolithic development is disappearing. Despite the best open tools today’s cloud native use cases continue to pose developers challenges to scale better, provision granularly at cost and migrate workflows securely. Of course, the need for utmost pairing of APIs and Microservices always haunts them. Microservices have replaced shared application servers and they offer single runtime. They are bunch of loosely coupled services working in harmony across hybrid environments and distributed hybrid cloud and multi clouds. Glitches still arise when even a suitably coupled API fails to provide its discrete components the way the Application logic demands in real time. A subtle implementation error in API can cause run time issues and jeopardize the quality of IP flows earmarked for a container or container cluster. This paper will compare and contrast the process and mechanism to produce business logic in containerized clouds through coupling of Microservices and Declarative API vs one in heterogeneous (less automated) legacy IT.

 2.0 Declarative API

A declarative API allows developers to declare or specify the desired state of their resource thereby keeping the current state of Kubernetes objects in sync with the desired state. The controller interprets the structured data as a record of the user's desired state, and continually maintains this state. A declarative API is exclusively suitable for cloud native architectures as one can use more annotations and reusable modules from the library and avoid extra re-coding. While APIs and microservices go hand-in-hand, it’s specifically declarative APIs – as opposed to the other primary type of API, the imperative API – that helps make microservices more feasible with a better business logic. A declarative API indicates what the developer is trying to achieve, as opposed to an imperative API, which indicates precisely how it’s to be done. It’s more of a high-level construct. Moreover, a Declarative API allows one to build flexible and resilient systems using independent services. Thanks to Kubernetes which allows us to simply declare what we want to achieve. When it detects conditions outside the desired state, it automatically takes steps to bring them back in line. A powerful paradigm is visible in today’s fast-changing IT environments. We all know that today’s IT community while processing cloud and Microservices cannot even think of making manual adjustments midstream while end to end automation is in full play.

3.0 Microservices and HTTP APIs

Microservices is an architectural approach to building an application as a collection of small, independent services that run on their own and communicate over HTTP APIs. Often, cloud native architectures rely on containers (e.g., Docker) and serverless compute platforms meaning applications are smaller and composed at a higher level. We no longer extend an existing application’s functionality by creating or importing a library into the application, which makes the application binary larger, slower to start and execute, and more memory-intensive. Instead one builds new microservices to create a new feature and integrate it with the rest of the application using endpoint type interfacing (such as HTTP) and event type interfacing (such as a messaging platform). The reasons below explain why Microservices are So Efficient in today’s IT landscape .

1. Microservices break large, complex Apps into smaller pieces so that they can be developed, tested, and managed independently. This enables a single microservice to be updated or rolled back without affecting other parts of the application.
2. A Declarative API delivers discrete components to Microservices in real time 
3.  Applications are deployed as one or more stateless processes. Shared state shall be portable and loadable from a backing service
4. Software teams are distributed and microservices enable each team to own a small piece with service contracts acting as the communication layer.
5. DevOps, CD, Microservices, and containers form the four main tenets of cloud-native patterns. All of them have the same overarching goal of making application development and operations teams more efficient through automation
6. Scaling : It is achieved using horizontal scaling
7.  Both server side scripts (including scripts for Serverless too) and the Client side scripts are in full play during run time and also during throughout the CI/CD pipeline. 
8. Another help comes from CI/CD -Continuous delivery enables applications to get released quickly, reliably & frequently, with less risk.

I want to make it clear that just creating microservices does not lead to the service quality and delivery frequency required by digital business. Likewise, just adopting tools that support agile development or IT automation will not lead to the increased velocity of cloud-native approaches. Rather, it is a combination of practices, technologies, processes, and mindsets that will define success.

 4.0 Understanding Cloud Native Practices

A cloud native practice goes beyond ad-hoc automation built on top of virtualization platforms. Instead, it focuses on the orchestration, management, and automation of the entire infrastructure right up to the application tier. Also the job of monitoring is very important : Typically vendors like Datadog, New Relic, and AppDynamics monitor containers and microservices. Those offered by Splunk, Elasticsearch, and Fluentd help in log aggregration while Open Tracing and Zipkin help in debugging applications. Also adopting cloud-native practices needs a cultural change where teams no longer work in independent  silos. End-to-end automation of software delivery pipelines is only possible when an increased collaboration between development and IT operations team is with shared responsibility. A Service-based architecture, such as microservices, advocates building modular, loosely coupled services. Other modular architecture approaches — e.g., miniservices — that respect loose-coupling and service-based design help organizations increase application creation speed without increasing complexity. Please note that  the path to cloud-native applications can vary by organization

4.0 How Business Logic is generated and sustained in Clouds

In Cloud native architectures the Business logic is split across processes with remote APIs and with secure REST services. Unlike Application server in client server architecture (in On-premise) here Microservices are directly invoked by HTTP REST API calls. So at least 3 major changes in a cloud architecture are very distinct and they are as follows.

1)    A lot of serverless on-demand services and transactions. 

2)    Standards like RAML (Restful API Modeling Language) allow for the formal definition of REST APIs. Will be used mostly (RAML defines every resource and operation exposed by the microservices. 

3)    DevOps, AIOPs and test engineers to use Secure REST services in HTTP, HTML and JSON. This ensures Microservices to get purposely aligned and coupled with API for most seamless interoperability. Please note that Microservices are natively able to communicate with each other because of industry-wide adoption of standards like HTTP and JSON helping them to be intrinsically interoperable. .

5.1 An analogy to typical SaaS or Web Applications : Grasping Mechanism

Since typical web applications (based on Client-Server Model) are distributed applications, they are at least two-tiered. They act as a special kind of client-server applications, where a large portion of the functionality is pushed back to the server side despite the fact that the Web does not define what is behind the server. Web applications are multidisciplinary (software engineering, database modeling techniques, network computing, and effective interface design).They are built in a continuously changing environment where requirements are unstable and the user community is wider than before. SaaS and web applications handle information from various sources (text, graphics, video, audio) dealing with structuring, processing, storing and presenting this information an Application Server. But in a cloud topology -hybrid, public or multi cloud typically developers have to deal with Serverless and Microservices and A virtualized App server or even a Virtual Switch. In cloud native all run time code architecture is centered around responding to API and Microservices. Unlike this in On-Premise the application server will use markup languages such as HTML and XML to transfer and represent data and will work fine with scripting languages that can dynamically process, modify and generate data.  

5.2 A better Analogy will be with a 3 Layer Model

Let us revisit the popular 3 layer Model of Kappel (Kappel et al. 2006) to learn how of Business logic is generated and shaped in a typical legacy IT architecture and how it contrasts from the cloud native scenario where overall container-centric response mechanism of APIs to Microservices including run time software is so crucial. In both scenarios, eventually they all influence secure multitenant workflow migrations. 

Legacy IT Architectures : In this 3 layer model the most external /outbound facing is the View Layer (see fig 2 below) that is the visible part of the application, the one that interacts with the user. The layer in the middle is the Business Logic Layer, which serves as an intermediate between the View (or presentation) and the innermost layer, that is the Data Layer. This last one is where all the data used by the application is stored. Layered models in software development help the coder to know exactly what each part of the application does. It makes easier to construct the application, to debug it, and to maintain and reuse the code. In case if it is needed to exchange some details in the presentation of the content but the business rules and data models do not change, only one layer is affected. Even for more complicated changes involving all of the application architecture there are benefices, so a plan can be created in the overall but specifying exactly where the changes need to be.

 Fig 2 : The standard three layered architecture for Web Applications

6.0 Application Logic as Core foundation of Business Logic : In any IT Architecture Application Logic generates pretty much the core foundation of Business logic and it provides a robust business logic layer that incorporates business rules and metadata to customize and guide the behavior of actionable insights generated by AIOps. Additionally it invokes steps on how to interact conversationally with end users. It includes the ability to logically group fields, classify data, specify default behaviors, define preferred relationships, and more. Similarly DevSecOps folks also have a similar role and they contribute to the business logic layer by discarding false positives, updating the threat vector library and what they learn from SYSlogs, Metadata and SIEM outputs. Orchestrator also helps by allowing Users to create custom alerts and how risks can be mitigated or quarantined including defining how measures should be filtered, aggregated, and reported. 

 The Business Logic Layer : A deeper Dive

The central layer of the model in fig 2 deals with the logic of the program. It receives data from the upper level and transforms it, using in the inner application logics. It also retrieves data from the deepest data level and uses it to the logics. And, by integrating these two processes, it can do modifications in both levels as well. The Business Logic Layer contains the determinant part of the application logic. It includes:

a)  performing all required calculations and validations

b)  managing workflow

 c) state management: to keep track of application execution

d)  session management: to distinguish among application instances

e) user identification

f) service access: to provide application services in a consistent way

g)  managing all data access for the presentation layer

The Business Logic Layer is generally implemented inside an Application server (like Microsoft Transaction Server, Oracle Application Server, or IBM WebSphere). The App server generally automates a number of services like transactions, security, persistence, connection pooling, messaging and name services.

7.0 HTML 5 Video in Cloud Native (An Example) : Application Logic/Business Logic  

So let us sort out how developers typically will enhance the performance of Business Logic in this cloud native use case as shown in fig 3

• The developer will have to ensure that application receives its request from the UI and the data is sent to the server.
• A PHP script catches it and then make the calls for the lower level to get the needed data. When a response comes, either desired information or a failed request, it is dealt and then prepared to be sent again to the upper level.
• Developer has to ensure the CASB or cloud EPG (end point gateway)is fully operational and meets the recommended settings & guidelines
• DevOPs will typically use server-side scripts like PHP,ASP.NET, Ruby or CGI. or node.js.
• Developers ensure that any remaining computational processing is done without adding latency to the specified Flow throughput
• Developers will use tested HTML 5 codecs, XHTML, CCS , clientside (Javascript/ Flash

(Most efficient Server-side scripts generate rich content, despite the fact that these scripts produce the HTML that will be shown be the browser)

• Developer to chose a well conceived workflow automation system to monitor the lifecycle of video container cluster and its health at any time or point in the workflow 
• While using Microservices they probably will use ISTIO -an open platform to connect, secure, control, and monitor microservices, reducing the complexity of managing microservice deployments. It has done very well on HTML 5 video use cases
• The browser shows the content initially written or produced by the server-side scripts, and the client-side scripts are able to modify that content. A Javascript code, is used to validate data form and even to create drag and drop interfaces. It interacts with HTML through a DOM tree, that is a representation of the document in memory.
• HTML5 is praised for its flexibility specially where it touches the concept of responsiveness, that is the ability to change the content disposition according to the screen size. This is so as the availability of a page in different screen sizes and devices is extremely important. 

Fig 3 : A typical Docker Architecture for HTLM 5 video use case

8.0 Application Logic for Legacy IT vs Cloud Native

1. Having many possibilities like desktops, tablets, smartphones, wearable devices and even augmented reality or voice user interface, the range of technologies and targets for the view layer is very wide for both Legacy (on-Prem) and Cloud Native, and it shows both the importance of it to the user and reinforce the need of a logical division of the application for supporting such variety.
2. Please note the View Layer passes information to Business logic layer through forms, like a user log-in in a system by giving username and password, but there are other ways. AJAX, an asynchronous way to pass information to the server and get responses is most advisable to developers. AJAX is a great help in cloud Native and it speeds up the flow.
3. Asynchronicity : This comes from the fact that in a form the content needs to be passed and then the response will come after a page refresh, but with AJAX the requested information, that is the result of the user’s action will come in the actual page. It saves time and gives to the user the impression that the application is really interacting with him.

9.0 CONCLUSION

1. Hyperscale Cloud is a true living example as platform to deploy cloud native solution. It has gained and is continuing to gain great credence and acceptance while delivering scalability, flexibility and cost savings in various cloud topologies amidst mixed IT architectures.
2. Combining the capabilities of the hyperscale cloud with a centralized and easy-to-use cloud migration, automation and orchestration solution enable less technical IT admins to deploy and manage cloud desktops with ease. They can also use API and Microservices to enhance the Business logic with tremendous savings in TCO.
3. Also current multitude of Video use cases in Clouds poses another challenge : Mobility and the fast proliferation of smart and connected IoT devices will need less expensive and easier to use Declarative APIs, optimized automated Microservices to assume bigger role as cloud native VDI alternatives.
4. Usually embedding videos in webpages and apps with dynamic URLs goes fast but integrating videos with URL-based APIs and SDKs is time consuming. So the easier route is to deliver smooth video-streaming through multiple CDNs and live-stream from any device, including sharing on social media. Again Declarative APIs must be carefully selected here to pair them up with your Microservices you come up with.