What is a Serverless Architecture

Todefine serverless architecture (SA hereafter), consider what it’s not. SA does not mean the absence of physical infrastructure or machine. SA actually is a term that is from the Enterprises standpoint.

Putting up a backend infrastructure involves time and continuous maintenance. Setting up physical machines or virtual devices, installing applications, versioning, provisioning, scaling, load balancing, fail-safe mechanism, access restrictions..the list is endless. Backend as Service(BaaS) or cloud computing, in general, alleviates much of this task by doing the heavy lifting and hence, unsurprisingly, its popularity in software development. But there exists no silver bullet for any problem.

BaaS/Cloud comes with its own challenges. Imagine a service running on any popular BaaS platform which handles ’N’ number of requests every ’M’ minutes. Let’s assume this results in CPU usage of 5 %. With this rate if you compare the time the service is processing over a period of 24 hours, then a week, month and so on… the cost of usage is extremely inefficient. Enter Function as a Service(FaaS) or Serverless architectures.

FaaS or SA enables an Enterprise to run “on need basis” server components which are

• Ephemeral
• Stateless
• Auto scalable

1. Ephemeral

A Serverless Architecture essentially comprises of functions that run for a short duration and are triggered or invoked by an event either as a common HTTP request or time-bound (Timer). When such a request rises the FaaS platform kicks in, initializes (if not already) and the function is executed. Once the execution is done the system is closed till the next execution. Hence unlike conventional BaaS “always-on” setup, we have a “not always on” serverless architecture. Please note this process would vary from provider to provider

2. Stateless

SA is best suited for stateless executions. Since the server provisioning and infrastructure is now managed by the cloud provider, there is no guarantee that the state maintained by the previous invocation of the service will be retained. This does not mean that FaaS does not support stateful operations, but just states that any state needs to be handled outside of the FaaS instance. A very good example of a state full operation which is Serverless is uploading to S3 via AWS Lambda.

3. Autoscaling

The benefits of SA are huge when it comes to scaling. Horizontal scaling is automatic and handled by the underlying platform. If the incoming traffic is high on a particular point of time multiple instances of the FaaS is invoked. If there is a lull in the traffic the instances are automatically reduced. The platform even handles the underlying resource management and allocations

Implementation/Deployment

FaaS functions can be implemented across a wide variety of languages and they do not require coding to any specific framework or any library. For eg all major providers support languages like JS, Go, etc The code/function is written and is simply uploaded. With services like AWS lambda, the code can be written in the AWS console itself. There is zero configuration required. For small to mid-sized organizations like product startup, this is a significant thing

Pros

1. FaaS is extremely economical when compared to an existing cloud infrastructure as we saw in the earlier example. The cost of running a FaaS setup is simply based on how often and how long it’s used.
2. Since scaling is automatic and reliable, enterprises do not have to worry about the economy of provisioning new server instances or removing unused ones. Everything is provided by the service provider
3. With the economies of scale taken care of, enterprises or developers can focus on building better solutions. Moreover reduced costs enables enterprises to innovate and test newer products with shorter development cycles

Cons

1. FaaS is completely dependent on the service provider and hence issues on the providers end like an outage, downtime, maintenance, security will have a significant impact on the Enterprises service
2. Since FaaS is essentially a stateless server, the onus for maintaining the state falls on the client. This can result in repetition of logic and data across multiple clients
3. FaaS is essentially a temporal entity. Google Cloud Functions for example times out after one minute(can be extended also). AWS Lambda functions are for five minutes. Unlike an “always-on” instance of BaaS, FaaS run only for a short duration

Conclusion

Serverless architecture is simply a paradigm where the responsibility of setting up, scaling, provisioning server-side systems is delegated to another entity. It offers cost benefits, leaner development time which can have a cascading effect of benefits for an enterprise. At the same time, it simply cannot replace all the existing systems which are built on a different architecture model. What can be implemented as FaaS is context-dependent

Scrum vs Kanban

Scrum is a project management framework based on the principles of agile methodology (https://agilemanifesto.org/) which emphasizes small production cycles over short sprints of 2–3 weeks. Since its an agile methodology It also stresses on feedback-driven incremental changes incorporated throughout.

Scrum is widely used in the software development process, but the principles of scrum are industry agnostic. It can be applied to any process or domain or business vertical.

“Agility is principally about mindset, not practices.”
― Jim Highsmith, Agile Project Management: Creating Innovative Products

Backlog

At the heart of a scrum is a project backlog. A project backlog is a well-authored list of tasks generally known as “Stories.” Stories are measured, or story pointed with some metric. E.g., 1,3,5,8,13 or 5 hours, 10 hours. As a rule of thumb, a project backlog should have sufficient tasks/stories to last at least two sprints. A business analyst or product owner prepares project backlogs in close collaboration with the customer during a periodic event known as Sprint planning. Representatives from the engineering, designing, quality are also involved in providing inputs on feasibility, cost, and time factors.

Sprints

Sprints are the actual production cycle or development cycle. Usually, sprints run for 2 weeks. At the start of a sprint, the project manager/ product owner includes stories or tasks from the project backlog. The development/engineering team works on the same for the duration of the sprint. Teams determine beforehand what constitutes the completion of a task. Usually, a task is complete once it’s tested and verified by the QA or customer. The end of a sprint features a new addition to the state of the existing product. At the end of the sprint, the primary stakeholder reviews the product and gives feedback. This feedback is used as an input for the next set of backlogs. This iterative cycle of

planning->develop->test->review->planning

forms the backbone of the scrum framework. A project manager often doubles as a scrum master who conducts the day-to-day sprint meetings; known as a Standup.

Standup

Standups are conducted on a day to day basis and are strictly time-bound. The goal of standup is for the team members to give a status update on a day to day basis. Members give an update on

“What they did yesterday?”

“What they will do today?”

“What are the challenges for the same if any.”

As the name suggests, standups are conducted standing up to put the focus on short time frames for providing updates

Retrospective

Scrum encourages a team to be self-motivated and drives continuous improvement. A “Sprint retrospective” is held to deliberate on the work accomplished in the previous sprint. The focus is on learning from past mistakes, improve efficiency, and share findings, which helps the team to improve and increase productivity.

Kanban

“In the beginning, it’s advisable to focus on the flow of your work and the idea that your work actually has a “shape.”
― Jim Benson, Personal Kanban: Mapping Work | Navigating Life

Kanban is a project management framework based on the principles of agile methodology with particular focus on the visualization of production flows. Kanban aims to improve productivity and reduce delays in the value chain by continuous monitoring, feedback and reduced waiting across the workflow.

Like its famous cousin “Scrum,” Kanban can be used across any domain or workflow. Any existing workflow can be expressed or represented using the Kanban board. There is no need to modify a workflow to include Kanban. An elementary Kanban board can be created with three lanes; “Todo,” “In progress,” “Done.” Depending on the workflow, these lanes can be more or less.

Visualization

Kanban places emphasis on visualization of workflows. On the kanban board, a workflow or its derivative is expressed in a naturally flowing order from left to right. For e.g., In the software development process, the workflow would be expressed with lanes as such

||Backlog|| — ||Progress|| — ||For review|| — ||For test|| -||For deploy||

Each task is expressed with cards, or color-coordinated. For e.g., In-progress tasks are expressed with green stickers or green colors. In-review tasks are expressed in Red color or red stickers. The tasks are moved to the adjacent lane, once it’s completed. Unlike a sprint, Kanban is not time-bound. Once a task is completed, it’s simply removed from the board.

By visualizing a workflow in such a manner, teams can obtain vital information about the work output. Useful metrics regarding the time taken to complete a task, where is a task getting held up, what is the dependency of one task over the other can be easily found out.

Kanban was first designed for the production lines of Toyota with emphasis on unused inventory. The Kanban board gives instant clarity to the team if a task is sitting idle on a lane for a long time. To overcome this, Kanban allows setting a limit on the input such that tasks are not lying idle in a lane because of the unavailability of any resource. This is generally known as W-I-P limit (Work in progress)

Typical benefits of Agile development methodology

1. A clearer view of process flow which helps in identifying bottlenecks
2. Flexibility in execution by incorporating smaller incremental goals as opposed to a monolithic, one-time development
3. Focus on continuous delivery by producing a subset of working software which is added to the existing product
4. Better tracking of issues and tasks
5. Continuous feedback leading to Increased productivity
6. Allows for change at any stage of the project development
7. Focus on the user all the time; their feedback & input

The primary goal of Kanban and Scrum is pretty similar, i.e., help organizations reduce execution time, optimize resource utilization, improve productivity & provide insights to measure. Both Kanban & Scrum are models of agile execution. Kanban focusses on specific aspects of the production process, whereas scrum is an entire framework for development. Kanban strives to present a clear picture of the workflow, while scrum defines process, steps & routines for workflow execution. It’s not uncommon to find Kanban being incorporated in a scrum process

Design Thinking

S
ome of the most common approaches to solve a problem are situational or context-specific. For example, in the field of structural engineering, most of the challenges are solved by applying time tested rules in the field of civil engineering. For a problem that is considered less severe, a common approach is a trial by error. Mission-critical requirements and issues are solved by using a well-defined set of steps and strategies. The first reaction to solve any problem is to compartmentalize the problem into something which was solved earlier. The mind likes the comfort of the known after all. This is our primordial nature. These approaches have served us since time immemorial and will continue to do so. A common thread running through all these problems is they are well known, and they have been faced before plus they are well documented

In this digital age, when everything is connected, information is available within seconds. Thus ideas and theories are shared and accepted or rejected rapidly, and “Business gets done at the speed of thought” there is a proliferation of data and unsurprisingly problems! New collaborations undoubtedly lead to new products and solutions, but with that also comes a new set of challenges. The older and legacy ways of solving problems as discussed above fall flat when it comes to these new-age problems since they haven’t been encountered before. Take the endemic case of fake news via social media. It has resulted in cultural changes, the collapse of governments, polarised, and influenced democratic processes. How are we to solve these?

---

Design Thinking is a process or framework or a structured way of solving problems with a transparent, well-defined approach. Along with solving the issue at hand, it aims to develop new, creative solutions. It is centered around key principles of empathy, ideation, and prototyping. That's also how it differs from traditional problem-solving steps

Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.

(Tim Brown — CEO of IDEO)

Reflection is an underlining theme of Design Thinking.

(Pearl Zhu — Thinkingaire: 100 Game-Changing Digital Mindsets to Compete for the Future )

Design thinking is heavily influenced by the techniques used by designers(hence the name), but it doesn’t have to be solutions for design specific problems only. It can be applied to any field. It also includes concepts from a range of different areas like fine arts, technology, etc.

While there is no formal definition or framework for Design Thinking, it’s widely implemented in four steps.

• Empathy
• Define
• Ideation
• Prototype and Implementation

1)Empathy — Research your user’s need

At the heart of Design Thinking, lies empathy. An understanding of the user, person, or entity which has a problem. Design Thinking encourages the thinker to put him/her in the user’s shoes and see the problem from their point. Being empathetic also involves understanding a user at an emotional and psychological level. Much research goes on in this stage using well-documented empathy-building techniques like interviews, observations. The goal is to view the problem from the customer or users perspective

2)Define — State your user’s need

After understanding the user’s problem in the given context, the next step is to collect all the information gathered during the Empathy stage and to analyze them and define the core problem. At this stage, the objective is to identify the user’s need or problem not in terms of a problem statement, but rather an open-ended question. E.g., For a city that is facing an unprecedented water shortage, traditional ways of problem-solving would be how to dig more wells, how to desalinate from the nearest seawater source, etc. But design Thinking would first define the problem as “What are the different ways by which this city can save and reuse water?” The advantage of such an approach is it does not close itself to any solution. Instead of restricting the solutions to how to dig more wells, how to desalinate from the nearest seawater source, defining the problem expands the horizon for more solutions

3)Ideation — brainstorm for solutions

The issue is now understood in detail and with clarity, from a user perspective. Thus the ideation phase begins. This is a stage where the cost involved is less, this is a stage where failures are most feasible. Brainstorming leads to lots of ideas being thought of and shared. Creative solutions are considered without any judgments. The key aspect here is avoiding judgment or conclusion. Since the problem statement is well defined many different ideation techniques like mind mapping, daydreaming, redefining opportunities can be used to think of potential solutions. In this stage, it is essential to avoid prior perceptions. Ideas which are Wild, quirky, practical, pragmatic, outrageous they are all welcomed

4)Prototype and Implementation — Quick solution

Once a few initial ideas are considered viable, they are quickly prototyped. Usually, multiple prototypes are considered. At the end of every prototyping stage, feedback is solicited. The feedback enables the user and the designer to see the problem in a new light. Perhaps an earlier issue found with the problem statement wasn't really applicable. This feedback can be incorporated to tune the product to the customer's liking. This way, they can generate better solutions. If the prototype satisfies the problem, it will be implemented for production else the cycle repeats

---

The application of design thinking is not limited to building a new product or process or service. It can also be used for fixing problems with existing products or services. It can be used to optimize existing solutions. Design thinking helps the designers to see a problem in a new light, i.e. from a customer's perspective. This enables enterprises or any problem solver to offer more value to customers

What are Microservices

Microservices are an architectural pattern that classifies and implements an application into a collection of independent services that have a high level of autonomy. Usually, each of these services would be related to a single business group. Since these services are mostly autonomous, they can be built using different tech stacks. Microservice modules can be scaled, unit tested & modified with minimal effects to other modules in the system unlike the traditional monolithic architecture which is a collection of all the functionalities/services in one place

Microservices extend the principle of Single responsibility by focussing on a single capability or business domain. Which could be department specific, a region-specific, or any other custom business requirement. By decoupling the same from other services, development teams can iterate, test, build, and deploy the same in faster development cycles. Thus it's a natural fit for the agile development process. Microservices and API gateways usually go hand in hand. The reason being Microservices can be based on different protocols and stacks and a great deal of autonomy.

Let’s take an example to see how Microservices can help design robust, scalable systems. Consider an e-Commerce application which includes several services ranging from product details, purchase, cart, payment, history, details, so on and so forth. If this system is built in a monolithic fashion, the entire code, infrastructure, and database are centralized. Among other issues with a centralized setup, The only real option to scale this during peak traffic is running multiple instances of the same server. Plus when it comes to fault tolerance, a failure in one part of the system affects the others as well. Additionally, if a particular service needs to be updated or changed, to update the same, the whole system has to be redeployed after making the change.

Microservices help in handling such issues by separating each module and making them independent with well defined public interfaces. Along with an API gateway, microservice can offer a single unified interface for clients by abstracting the complexity underneath. Moreover, the independent, autonomous modules offer backend developers a scalable architecture with each microservice having the freedom to use a different development stack altogether

It’s tempting to ask how does this differ from a Service Oriented Architecture(SOA). After all, SOA also stresses on distinct components interacting amongst each other. The main difference between SOA and Microservice is that Microservices aims at modularising the system by building independent, self compassed units, unlike an SOA which focusses on building components that aim to provide services to other components by means of a common communication protocol. By that virtue, Microservice can be considered a fine-grained version of SOA.

Benefits

1. Since microservices are independent units, they can be worked upon by multiple small teams. This reduces the delivery time period and increases deployment frequency

2. In the event of any service failure, it can easily be isolated and fixed without any impact on other services

3. Individual units can be easily integrated into CI/CD pipelines

4. Components can be scaled based on a need basis. This reduces the cost and time of scaling the entire system to support a few modules.

Challenges

1. Microservices comprise individual components that are distributed. So the drawbacks associated with distributed systems apply here as well like reliability, latency, bandwidth, etc

2. Determining the boundary of a component is a complex process and requires an understanding of code dependencies

3. Depending on the number of modules the complexity of a microservice might increase more than a monolithic architecture

Conclusion

Microservice architecture offers tangible benefits for an application that has different modules spread across different requirements. But the implementation of the same has to be weighed against the need and complexity of the domain. As with any architecture, one size does not fit all and hence Microservices as a solution needs to be evaluated before implementation.