Recommended Audience: Anybody with an Infrastructure background
What to expect from this post: This will quickly prep for the discussion on DevOps and CI/CD Pipeline
Most of us understand infrastructure pretty well and when it comes to development, testing, or even DevOps for that matter, its quite challenging to understand what happens during the SDLC and CI/CD process.
Let’s dive right in to understand how servers, applications, environments, and IT roles have evolved over the years:
Server Evolution:
So, if you look at the server technologies, we’ve seen how it all started with physical servers, then evolved into virtual servers, then self-service, on-demand based cloud resources (which is obviously virtualization behind the scenes) and then eventually led to the containers. We will discuss the evolution of physical to virtual to the container in the next part when we talk about Docker/K8S.
Application Evolution:
If you look at the Application types, we can divide them into three types:
STANDALONE APPS: Firstly, they all started as standalone applications also called desktop/client applications, installed directly on the desktops. (Ex: Office, VLC Player, Adobe, etc.)
WEB-BASED APPS: To overcome the problems of single-user access, came the hosted/online applications, so the ‘n’ number of people can access this app at a time. And where do we host these web applications? – Web Servers (Ex: Tomcat, Apache, NGINX, HTTPD (apache), IIS, IBM’s IHS etc.) – usually it is all the static content.
ENTERPRISE APPS: Then eventually it all led to the enterprise applications, once they identified that IT can help enterprise business, they realized that they need to have business logic included in their apps. That created the need for application/middle-tier server technologies which can provide all the facilities/features/functions that are required by your enterprise application. This could be a hosted online solution, however dynamic (content) in nature. Various services such as access, messaging, email, transactional management, high availability was included in this middle-tier layer (Ex: WebSphere, WebLogic, JBoss, .Net Server, etc.)
Application Architecture:
The application evolution can again be divided into three categories as outlined below:
MONOLITHIC: Applications used to be monolithic earlier – everything on the same machine – all the applications are bound together or tightly coupled – probably accessed via a browser. MONOLITHIC APPS ARE TIGHTLY COUPLED.
N-TIER: To serve the enterprise requirements, they started splitting application components onto multiple servers – which came to the client-tier or front-tier, middle-tier and backend-tier architecture. In other words, in the front there are web-based access layer applications, in the middle are your business layer applications and supported by the backend/database layer applications. N-TIER APPS ARE DE-COUPLED.
MICROSERVICES: Now with a microservices architecture, we started segregating the things furthermore – each of the middle-tier might further be divided into multiple small services and hosted on individual workloads called containers. MICROSERVICES ARE LOOSELY COUPLED.
The main reason being, we now allow any device including mobile devices that can access these apps + additionally there might be messaging services can also access the applications (example: send a text msg from your mobile phone to get your account balance) – they need to be quick and scalable and environment specific to be able to serve these requests. And also, by breaking down the functions into smaller pieces those single pieces can be updated or if a single piece of function breaks, that doesn’t take down the entire application. For instance, if the credit section of a banking application is affected with a bug in the new update, then the entire application need not be down, all the other functions such as debit, loan, mutual funds, etc. can still be functioning without being interrupted.
Environments:
You’ve various environments based on your organization’s needs. Usually, used in the order of Development, QA (functional, E2E, Regression, UAT tests), IAT (pre-pod – integrated acceptance test – check all the integrations of the application), Performance, Pre-staging and Prod (also called as Live Environment) – always end-user requests come to the Prod environment.
Roles:
You just can’t generalize the entire infrastructure team as developers and operators, but for the sake of getting into the DevOps discussion:
- When I say developers, we’re assuming Business Owners, Business Analysts, Developers/Coders, Testers, Software Architects, Project Managers, etc.
- And when I say Operators, I’m referring to Systems, Networks, Storage, Security, Database Architects, Engineers, Admins, etc.