Part 1: Intro to serverless
Tags: aws, cloudcomputing
Published: 2023-07-03 17:59:03

As Im learning about cloud computing and reading up on various sources including aws, I thought I would share some of my learnings. 

**Why serverless?**
Building Secure Reliable and Cost effective architecture is important for IT professionals. Many organizations are replacing monolithic methods with microservices methodology. 

**What are Microservices?**
- Architectural and organizational approach to software development. 
- Software is composed of small independent services. 
- Communicate over well-defined APIs. 
- Owned by small, self-contained teams.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p5axl8666t1zllf9lcyq.png)

**Tightly versus loosely coupled**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2zawz27pe4exv12d72as.png)

**Monolithic application (tightly coupled)** 
In a monolithic application, if one piece were to fail, the entire application would crash, as this example illustrates. If there is a spike in demand, the entire architecture must be scaled. Adding features to a monolithic application becomes more complex as time goes on. Pieces of the code base must work with each other to sync properly.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/srwldz5a1ubr2bw2l5k1.png)

**Microservices application (loosely coupled)**
In a microservices architecture, an application is built as independent components that run each application process as a service. These services communicate through a well-defined interface by using lightweight APIs. Services are built for business capabilities, and each service performs a single function. Because they are independently run, each service can be updated, deployed, and scaled to meet demand for specific functions of an application. If one component fails, the other components remain active, as illustrated.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ubxdcl7zn9i2hg3emqm4.png)


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lxizapn92oo7za7tmdrm.png)

**Benefits of microservices**

**Use public APIs**
Microservices communicate over APIs. In fact, doing so is the only way to realize the benefits of microservices. Don't be tempted to circumvent that rule. By communicating with APIs, you can modify a database and maintain it without affecting communications or having to repoint interfaces. The public API is a contract between your microservices and its clients.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/heth66tyi4rzx0xqk4xy.png)

**Use the right tool for the job**
Because every service is built for explicit functionality, you can choose the right tool for the job. The development team for Microservices B can add Amazon Aurora Service or change to Amazon OpenSearch without affecting Microservices A. You can also make changes to the entire language framework, which gives you the flexibility to code in the language that is best suited to an application. By choosing the programming framework that works for the team, the development team for Microservices B can avoid depending on other teams for their knowledge of specific frameworks.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q2ucsajj9r3u2ibthpam.png)

**Secure your services**
 Microservices must be architected to provide security at every step. The defense- in-depth approach is a common method of reviewing each step of the application to determine areas where additional security controls can be implemented. In a microservices environment, this arrangement includes the application level, API level, network layer, and AWS Identity and Access Management (IAM) configurations. The API is the entry point. Amazon API Gateway can perform authentication and authorization for services and act as security control for microservices by enforcing throttling and obfuscation of internal resources.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qr6cvyzaixpkbfo0ouaz.png)

**Be a good citizen**
As this environment of microservices grows and expands, it becomes important to be a good citizen. As a service owner, you must understand how other services are calling you. The service owner will identify the client's use case and register them in the service registry. As a client of services, you must understand the service that you are calling.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ejmv8d20z892bhcmnhth.png)

**Company transformation**
Going from a monolith to microservices is more than a technological transformation. The shift requires transformation in the organization and communication mechanisms between teams. Automation is the key to rapidly deploying stable applications. Small development teams ("two-pizza teams" or no more than the number of people who can be fed with two pizzas) focus on producing a single microservice. They can send the service through an automated delivery pipeline and release a service into production with everything, from the build step forward, being automated. By organizing the software as a grouping of microservices, the development teams are decoupled and can efficiently release updates to their microservices on their own.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8opqy243hnkemxp71zby.png)

**Automate everything**
Some examples of some tools can help with automation. 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jbmzwru0pb9vwwnqlzp5.png)

**Downsides of monoliths** 

- All processes are tightly coupled and run as a single service.
- Adding or improving a monolithic application's features becomes more complex as the code base grows.
- Dependent and tightly coupled processes increase the impact of a single process failure.

Serverless applications dont require you to provision, scale or manage any servers. 

You can build them for nearly any type of application or backend service, and everything required to run and scale your application with high availability is handled for you.

**Why serverless?**

- developers dont need to worry about managing and operating servers of runtimes and can focus on other areas, thus can focus on core product 

**Event-driven architectures** 
-  Uses events to initiate actions and communication between decoupled services. 
-  Change in state, a user request, or an update. 
-  Information published for other services to consume it.
-  Events are the primary mechanism for sharing information across services.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/r1k4wtan8pu18ks6clfo.png)
 • Microservices is a method of building your architecture. 

• Serverless is a service that is used to build your architecture. 

• Microservices is the method of loosely coupling sections of your architecture. 

• Serverless services are the tools that you use to build out those sections of your architecture. 

• It's common to use a blend of both serverless and nonserverless services.