Product Engineering & Development | Applied AI Consulting

Understanding AWS IAM

Wed, 21 Dec 2022 10:48:00 +0000

Architecting your environment in AWS—or any cloud, for that matter—is just the beginning. Like any other asset, it must be managed. But the typical cloud has many moving parts, i.e. services that need to be run, monitored, and managed. The right thing to do, of course, is to delegate tasks. But delegating tasks means assigning permissions, which can be misused—wilfully or otherwise—so these too need to be managed. AWS Identity and Access Management (IAM) is a service that allows you to do just that. IAM enables you to control access to all the AWS resources in your infrastructure as well as those you might need going forward. IAM allows you to control who is allowed to use which resources.

When you first create your AWS account, you start with a sign-in id. This identity, called the AWS root user, consists of the email address and password you used to register for the account. AWS strongly recommends that the root user credentials are properly safeguarded and used only to perform certain tasks, viz, which only the root user can perform. The full list of these tasks can be accessed in AWS documentation, at

https://docs.aws.amazon.com/

IAM Features

Shared access

IAM allows you to give other people permission to use and administer resources in your AWS account without sharing your password or log-in.

Fine-grained access

You can give different people different permissions for specific resources. For instance, you can give some people access to Amazon EC2 (Elastic Compute Cloud), S3 (Simple Storage Service), DynamoDB, and other specified AWS resources, you can grant read-only permissions to administer certain EC2 instances, or access only certain S3 buckets. You can even allow outside users who might already have passwords elsewhere (with an internet identity provider, like Facebook or Google, for instance) to gain access temporarily to your AWS account.

Authenticating IAM Users & Groups

All users must be authenticated before using any AWS services, which can be accessed in the following ways:

Through the AWS management console—a browser-based interface

Through the AWS command line interface and command line tools—this is faster and more convenient than using the console. The tools can be used to write scripts that perform AWS tasks

Using AWS software development kits (SDK) These kits are provided by AWS and consist of libraries for a variety of programming languages and platforms like Python, Ruby, .Net, Android, iOS, etc

IAM HTTPS API—access IAM programmatically by issuing HTTPS requests, but you must include code to digitally sign requests with your credentials

Users and User Groups

Each user has specific permissions with access to specific resources to perform specific tasks. You can create users in your AWS account to match people in your organization.

As the number of users managing your account grows in number, you might find it easier to manage permissions for multiple IAM users using IAM Groups. Each member of the group will have the same permissions.

After a user has been authenticated, they need to be authorized to use certain resources. This is because by default users are granted access to anything in your AWS account. You need to manage this by creating a policy. You can assign the policy to an individual user or a group. When you assign a policy to a group, all the members in the group get the same permissions by default.

IAM Policies

An IAM policy is a JSON document that lists permissions explicitly. Any actions or resources that are not granted in the document are denied to the user. The IAM policy tells you:

Who is authorized? This could be a user/group or another user in AWS

Which task is allowed?

What conditions must be met for authorization, e.g. IP address?

The resources on which the authorized tasks can be performed

IAM Roles allow users to assume certain permissions temporarily in order to undertake specific tasks

IAM Roles

An IAM role is an identity that is linked to resource-based policies.

It allows you to grant access to users or services that wouldn’t normally have access to your AWS resources. These users or services can temporarily assume the specific role and get the security credentials needed to make AWS API calls.

It is similar to a user, in that it grants the user permission—or denies permissions—to do certain things. Roles do not have any long-term credentials like access keys or passwords; these are created dynamically when a user is assigned to a certain role. Note that a user who assumes a role gives up his/her own permissions and assumes the permissions granted with the role. Roles offer a secure way to pass credentials temporarily to a user so they can complete a certain job.

Takeaway

AWS IAM lets you create users and groups to help you manage your AWS cloud. You can manage IAM roles and their permissions using policies that specifically grant or withhold permissions to take certain actions on certain resources. When you attach a policy to a user group, all the members of that group assume the same permissions. You can also grant temporary permissions using IAM roles. IAM also enables the use of identity federation to allow existing entities in your enterprise to access your AWS account without creating separate IAM policies for each identity.

Choosing between SQL and NoSQL; Amazon Aurora and DynamoDB

Tue, 29 Nov 2022 12:42:31 +0000

Everyone who has worked with databases is probably familiar with relational databases, and the crown jewel of relational database management systems (RDBMS) is SQL. But over the years as data volumes have exploded, and storage & processing power with it, a new type of database also evolved along with it. A database that could collect this new and vast volume of data in its raw format and analyze it faster than traditional means. This is NoSQL. Thus the two broad categories of data can be described as SQL, or structured query language, and NoSQL, or non-structured query language. This article takes a closer look at the differences between both, and compares the two crown jewels of Amazon’s database offerings, Amazon Aurora and DynamoDB

Structure

SQL is by no means obsolete, it is still widely used and is excellent for querying relational languages, and this is the main differentiator between the two. SQL databases use fixed schemas to store data. NoSQL databases are schema-less. This can be better understood with an example, say you have to save data related to an address book. The table you will probably use will have a definite structure: say, names in one column and other parameters, like address, email id, tel number, etc in different rows. Now say you suddenly need to add a row for hobbies; this is not possible, as there is no row defined for this in the schema. And this is where schema-less tables score over SQL. In a similar use case as the one described for SQL, you do not need to add a predefined schema for the new information. Each row is simply a repository for different information. So, for example, you can have the name, age, hobbies, and email in the first one, and name, sex, address, and telephone number in the next. Each one can hold different information. So the biggest difference between SQL and NoSQL is that the former is structured to have a defined schema and the second is schema-less and holds unstructured data. Note here that a NoSQL database can also hold structured data.

Types of NoSQL databases

There are four basic NoSQL types of databases: document databases, key-value databases, wide-column stores, and graph databases.

Document databases store data in documents, like JSON files, containing pairs of fields and values. Values can be objects, numbers, booleans, or arrays. Key-value databases store data in keys and values. Wide column types store data in tables, rows, and dynamic columns. Lastly, Graph databases store data in nodes, which can be information about people, places, things, etc, and edges, which store information about relationships between the nodes.

Schema vs Schema-less Pros and Cons

The big advantage of SQL databases and their predefined schema is that the data is better set up. The indexes, secondary indexes, foreign keys, are optimized and The database already understands the columns and rows and what is where, so it is easier to query. Thus, SQL databases are good for joints and complex queries, like those involving multiple tables. As there are predefined columns, foreign keys that the database understands, you can link an SQL database to multiple tables, so you can join tables and run sub-queries, etc. Schema-less NoSQL databases have different data for every item or row making it impossible to define the different keys that the NoSQL database supports. And the absence of a predetermined structure makes it unsuitable for complex multi-table queries.

Transaction Processing

In terms of processing transactions, SQL databases follow the ACID principles, where A-C-I-D is an acronym for:

Atomicity: where changes are performed in unity or not at all

Consistency: from the time a transaction starts till it ends, the data state is consistent

Isolation: the intermediate status of a transaction is invisible to other transactions

Durability: changes to data remain even if there is a system failure

NoSQL databases follow CAP or the CAP principle, which refers to

Consistency: when the nodes have the same data item and every node returns the same after a successful write. It implies that every client gets the same view of the data

Availability: when the system sends a successful/unsuccessful message after every read/write operation is completed

Partition tolerance: means the system continues operating even if connecting nodes in the network have a fault

Amazon Databases

AWS offers a choice of both types of databases. In SQL, you have Amazon Aurora and Amazon RDS; Amazon DynamoDB, Amazon DocumentDB (which is compatible with MongoDB), and Amazon Managed Apache Cassandra Service. But AWS also allows you to run any database you might prefer on EC2, although it is recommended that you pick one of AWS’s native databases preferably.

Vertical Scaling vs Horizontal Scaling

Amazon Aurora

Amazon Aurora is Amazon’s premier SQL database. It was released in 2015, and is based on the Relational Database Management System (RDBMS) model. It is a different beast than SQL but it supports SQL language. It is compatible with MySQL and PostgreSQL, but much faster than both.

Amazon Aurora uses a concept called Referential Integrity, which doesn’t use Foreign Keys. Referential Integrity requires that the values in the foreign key column must be present in the primary key that is referenced by the foreign key or the values must be null. This ensures the data in the database remains consistent. It keeps incorrect records from being added, deleted, or modified.

Where DR is concerned, Aurora allows backups and snapshots

To ensure high availability for your Amazon Aurora Database you can choose multiple AZs and read replicas.

Scaling in Amazon Aurora happens vertically. This means choosing a bigger/more powerful server, i.e. EC2. Although Serverless Aurora scales automatically.

Amazon DynamoDB

DynamoDB is a proprietary database developed by Amazon in 2012. It is a fully managed, scalable database service built for the cloud. Unlike Aurora it doesn’t use the concept of Referential Integrity; so, there is no Foreign Keys DynamoDB’s primary database model is a document store and a key-value store.

As with most NoSQL databases, it doesn’t support SQL query language; Unlike Aurora, which only supports the Master-Slave replication method, DynamoDB supports most replication methods.

It supports cross-region replication. This means that if you have a table in US East one, which is replicated in US West two, you can insert a row in either one of the tables, it will be instantly replicated in the other

It is highly available and resilient as it instantly replicates across three AZs.

DynamoDB scales horizontally. This means it spins out multiple read replicas to handle spikes in traffic. It can handle more than 10 trillion requests/day with peaks of more than 20 million/second. This makes it much more scalable than Aurora, although Serverless Aurora *does *scale automatically, it is not as scalable as DynamoDB

DynamoDB is inherently durable, enabling Point in Time Backups.

Choosing the ideal database doesn’t mean picking one or the other. Rather it’s a matter of picking the right tool for the job. For instance, say you’re in charge of a project and you choose to work with a NoSQL database. This doesn’t mean you have to force-fit everything to the NoSQL database, even if it would be a better match for SQL. With most modern applications being Microservices-based, the choice becomes easier, because microservices architectures are autonomous, in that you can pick SQL or NoSQL database, whatever fits the solution better. At the end of the day, the choice is not between SQL and NoSQL or Aurora vs DynamoDB but the actual case, performance levels, and cost requirements.

Kubernetes Security 101: Understanding RBAC and Service Accounts

Thu, 24 Nov 2022 12:52:24 +0000

Kubernetes’ API only responds to requests that it can authenticate. This means that in order to properly secure your Kubernetes API, you need to secure your Role Based Access Control (RBAC) policies. RBAC is basically a mechanism that allows access to only users, i.e. as per permissions that have been set by you as admin. So how do you secure your application running on Kubernetes in AWS?

Let’s begin by revisiting the basics. Your application is running in a pot and to function properly you need to give the pod access to AWS resources, like creating a load balancer or attaching security groups. If your application were running in a standard Amazon EC2 instance you would simply attach IAM (Identity & Access Management) roles with policies allowing certain actions (for example, the ones mentioned above). Now since the pod is running in Kubernetes, you can’t simply attach an AWS-specific service like IAM, instead, you need to go back to the source, i.e. the Deployment Manifest. But the Deployment Manifest, too, is a Kubernetes construct, and as we noted, you can’t simply attach AWS cloud-specific constructs like IAM. Rather, we need to abstract such cloud-specific constructs. This will allow Kubernetes to run in other cloud platforms—AWS, in this case. This simply means inserting a layer in between…i.e. Service Account.

In a nutshell, the stack goes something like this: policies that allow access to resources that you specify. These policies will be attached to an IAM role, and this IAM role is attached to Service Account—which is a Kubernetes construct—and finally, this Service Account is connected to the Deployment Manifest. Since the Deployment Manifest-Service Account is running in AWS EKS, it needs a way to connect with AWS IAM service to validate the permissions and policies you have set. So what we do is use an IAM OpenID Connect (OIDC) service—an authentication protocol—to connect your policies to your cluster. This is set up at the cluster level, and only needs to be set up once.

Now, if you run “cubectl get sa account” you will get “default‘ in return; however if you run *cubectl sa -A *(A in Capital) it returns a list of all the Service Accounts in your Kubernetes cluster. For the purposes of this article, we will pick alb ingress controller. The alb ingress controller monitors ingress and interacts with the Kubernetes API server. When the ingress resource is deployed, it allows you to create Application Load Balancer Security groups, attach a Security Group, etc. The IAM Role associated with each Service Account is connected to a role name and in you look up the role name you can see all the policies connected with that role, e.g. EC2 security group, role to create load balancers, etc. Remember, the Service Account is attached to an IAM Role, and has nothing to do with the Kubernetes cluster or the pods in which your application is running. Now the pods—which are running the application need access to the Kubernetes cluster. This is where ClusterRole comes in.

Role & ClusterRole

Just as an IAM Role gives access to specific AWS resources, ClusterRoles give the pods access to resources on a cluster level. The roles allow you to create/delete/list on the nodes, pods, namespaces, and all other resources you need on a cluster level to run your application effectively in the pod. In other words, to run your application effectively you need access to both AWS resources as well as Kubernetes cluster resources. ClusterRole gives you access across the cluster; if you have Admin-level access you can do just about anything, which is why Admin ClusterRoles should only be used with caution.

Role binding grants permissions as defined in the role to a user. Permissions can be within a namespace or cluster-wide, the former is known as RoleBinding, and the latter, ClusterRoleBinding.

If you look at a typical manifest file, at the bottom you can see information about the Service Account creates, the name of the Service Account, and in which namespace it has been created. Above this, you can see the ClusterRole that has been created, under ‘Rules’ you can see which resources it has access to and the kind of actions this ClusterRole can take. To connect this ClusterRole with the Service Account, you have ClusterRolebinding in the center layer. The ClusterRole is referenced with the name specified.

ClusterRoles are reusable, i.e. they can be replicated for another namespace. All you need to do is create a Service Account in that specific namespace and reference the same ClusterRole to that Service Account.

Role is not an IAM construct, it is a Kubernetes term.

Both ClusterRole and role represent permissions. These are similar for both role and ClusterRole but role defines permissions with a specific, defined namespace, and works only on resources—such as pod, replicaset, and cluster—specific to that namespace.

ClusterRole, on the other hand, defines permissions across the cluster, i.e. not specific to a particular namespace. In a nutshell, if you put a namespace when you define a role it becomes a regular role; if you don’t put a namespace when defining the role, you’re not tying it to any specific namespace and it becomes a ClusterRole.

Role Based Access Control (RBAC)

There are two basic areas to secure in a Kubernetes application: one is your application’s security, and the second is security for you as the user. ClusterRole, Service Account, Role Binding, etc all were aspects to secure your application. Security for the human user consists of granular permission specific to the user type. For instance, for a DevOps person, you’d want to grant permissions, like give, create, get, and list, in a particular namespace or on deployments, replicasets, and pods. To do this, you will first create the Kubernetes role defining access to resources in that namespace. (This is a namespace-specific Role). Then you will map that Kubernetes username to the Role using RoleBinding. Finally, you need to map the AWS IAM username to the Kubernetes username and group using Configmap/AWS auth. Both Rules and ClusterRules are similar, so you can define API groups, resources verbs, etc.

You can have two namespaces running in the same node (or EC2 instance), with different pods, and each namespace running a different application. You can create a Service Account for each of the namespaces, tie each to an IAM Role and connect that to a cluster role specific to the corresponding namespace. Now each of the IAM Roles and Cluster Roles in the two namespaces can have totally different permissions and access, even though they are running in the same node/EC2. The reason for this is that if you put an IAM role associated with a particular node that has access to all the pods, you are, in effect granting permissions to all the pods running in that node.

Finally, please note that this concept is only available from Kubernetes version 1.14 onwards; it replaces Cube2IAM.

Exploring Container Orchestration Options with AWS ECS, EKS, and Fargate

Mon, 14 Nov 2022 06:20:55 +0000

There is no doubt that microservices came as a boon to developers in the cloud. And one of the reasons for their growing popularity is the innovation we know as the containers. Containers basically contain everything needed to run an application—such as the configuration, code, runtime engine, etc. Containers still need to be managed though. They need to be deployed, networked, unneeded replicas must be deleted when not needed, crashed containers must be restarted, etc. All of this is not possible to do manually. Remember even the most basic microservices app will comprise tens or hundreds of containers. Clearly, some sort of automation tool is required. Enter container orchestrators: Kubernetes, Docker Swarm, Apache’s Mezos, Hashicorp’s Nomad, and AWS’s own container orchestration tool: AWS Elastic Container Service (ECS).

AWS ECS

Container orchestrators like ECS manage the entire lifecycle of a container, including starting, rescheduling, load balancing, etc. Let’s understand how this works.

The first step would be to create an ECS cluster. This will include all the services needed to manage individual containers in the cluster. In other words, the ECS cluster acts as the control plane for your VMs that are running containers. These VMs are nothing but EC2 instances, which will host the containers and be managed by us. The EC2 instances will have the container runtime and ECS agents installed. This will enable the ECS processes to communicate with individual EC2 instances and manage them. I.e. you can delegate management of your containers so you don’t have to contend with the hassle of repetitive, manual container management tasks.

However, you do still have to manage the VMs, i.e. the EC2 instances. Viz: create the EC2 instances, join them to the ECS cluster, and ensure you have sufficient instances and resources to schedule the next container and manage the server OS, as well as the container runtime. On the positive side, you have complete access to your infrastructure. If you want AWS to manage the hosting infrastructure as well, there is a solution:

AWS Fargate

AWS Fargate is basically a serverless compute engine designed for containers. Since it is fully managed by Amazon you’re spared the task of provisioning or managing servers. Amazon assumes the responsibility of managing your server infrastructure. And of course, you only pay for the resources you need to run your containers.

Think of Fargate as an alternative to EC2, but instead of provisioning EC2 instances and connecting them to your ECS cluster, you delegate this to Fargate, which will spin up the VM to run your container, after analyzing how what resources—CPU, RAM, Storage—it needs to be deployed and run. All of this happens automatically. All you need to do is hand over your new container/s to Fargate—using the interface. The advantages for you are many. To begin with, you don’t have to bother about having sufficient EC2 instances or resources to schedule a new container. You don’t have to provision any infrastructure before you deploy your containers and you only use as much infrastructure and resources as your containers actually use—which means you pay only for what you use. In comparison when using EC2, you pay for the whole server even if you’re only running a few containers or none. With AWS taking on the responsibility of managing your infrastructure, you’re free to focus on the management of your actual application itself. On the flip side, if you need access to the actual infrastructure running your containers, EC2 is a better fit.

One big advantage of running your container application on AWS is that you have access to multiple supplementary services from AWS. For instance, CloudWatch for monitoring, Elastic Load Balancer (ELB) for load balancing, IAM for permissions, etc.

You will also have the storage (Etcd) replicated so you don’t lose data like cluster configuration. AWS also handles data backup. In a nutshell, with EKS the Kubernetes master nodes are not your worry any longer. All you need now are the worker nodes, the infrastructure that actually runs your containers. Here, again, you follow the same process as in ECS. You create EC2 instances—the compute fleet—of virtual servers and connect them to the EKS. This gives you a complete Kubernetes cluster and you can connect to the cluster using the Kubectl command and begin deploying containers inside the cluster.

Communication in ECS happened through the ECS agent installed on the EC2 instances. This allows the control plane to communicate with individual nodes. In the Kubernetes world, the worker nodes and master nodes communicate using Kubernetes processes. These are not specific to AWS.

As far as managing your EC2 instances is concerned, in EKS too you have to manage the OS yourself and the processes running on your EC2 instances. But you can make it easier on yourself by choosing semi-managed EC2 instances. This allows you to group your worker nodes logically. The semi-managed option creates and deletes EC2 instances, which makes it easier to manage. Your node groups automatically have all the necessary processes installed on them, so you don’t have to install container runtime Kubernetes worker processes to make worker nodes.

You still have to manage other tasks—autoscaling, for instance. Autoscaling is not configured out of the box. You need to configure settings in Kubernetes and the AWS side of things to make autoscaling possible. And you have to handle the creation of new EC2 instances yourself. If you don’t want this hassle too, simply use Fargate. You can also have your containers running on EC2 instances and Fargate simultaneously for the same EKS cluster.

Amazon EKS

But what if you still want to leverage the AWS ecosystem and you’re using or want to use Kubernetes? After all, it is the most popular container orchestration tool right now. Amazon has a solution for that as well: Amazon EKS (Elastic Kubernetes Service). As mentioned, if you’re already using Kubernetes, i.e. your project is deployed on a Kubernetes cluster and you want to put it on AWS infrastructure, you can still retain your Kubernetes tool, instead of using a proprietary tool like ECS. This way if you decide to migrate to some other platform at some future date, you can do this easily with EKS; because, although AWS is managing your Kubernetes cluster, Kubernetes itself is not proprietary to AWS; it is an independent tool, so you can use it anywhere—on another cloud platform, or even on-premises if you have your own infrastructure. There is no doubt that Kubernetes is a very popular orchestration tool, and you also have access to a big community and multiple tools and plugins being developed in the Kubernetes world. However, if you’re using other AWS tools and services in your Kubernetes cluster, you will have to replace them with other options, as they are specific to Amazon.

EKS working on AWS infrastructure is similar to how ECS works. So you create a cluster—this represents the control plane and will be the master nodes in your EKS cluster. AWS will provision Kubernetes master nodes in the background, and these master nodes already have all the necessary Kubernetes master services installed—all of this from provisioning to management is handled by AWS. Another thing that AWS does for you is to automatically replicate the master nodes across the Availability Zones (AZ) in the region you’ve selected. I.e. if there are three AZs in your region, you will have automatic replication of your master nodes in all three AZs.

Conclusion

AWS offers a choice of container orchestration tools. If you’re locked into AWS, you have ECS, whereas if you prefer to keep your options open, or are already using Kubernetes, you can continue to do so, while leveraging AWS infrastructure. For users who don’t want any hassle of managing the underlying infrastructure, AWS offers Fargate—a serverless compute engine designed for containers. And it works with both ECS and Kubernetes. Fargate saves you the bother of managing your server infrastructure so you can focus on your app development instead. And of course, you have a cost benefit as you only pay for the infrastructure and resources you actually use.

Serverless or Containers, Which is the Better Option?

Mon, 14 Nov 2022 05:54:53 +0000

Both serverless and containers are new disruptive technologies designed to allow developers to build applications with more flexibility and at lower costs than the traditional method of building applications that are hosted on servers or virtual machines (VM). But which one is the better option? As we will see there are several differences between the two and the choice of which to use depends on the needs of the application, traffic predictability, etc.

Serverless Computing

The first thing to understand is that although the term is ‘serverless’, it doesn’t mean there are no servers. As of now, at least, every workload needs a server. But in the case of serverless, the servers have been abstracted away by the Cloud Service Provider (CSP) so the user doesn’t have to bother about managing the underlying infrastructure.

Management hassle

Since the CSP assumes total responsibility for the actual servers, with serverless computing you’re saved such tasks as provisioning, monitoring, patching, scaling, etc.

Since you do not control the underlying environment, it also means that you cannot install software, like Web Servers or Appservers

Automatic scaling. You can, however, install code libraries—for instance, if you have a Lambda function written in Python and has some dependencies on certain libraries, you can package the libraries with Lambda.

Another distinctive feature of serverless computing is that it automatically scales up and down in tune with actual traffic. This means you do not have to define an autoscaling group or schema. The CSP makes it happen for you.

Pay for what you use

Not only do you not have to bother about the infrastructure, but you’re also not billed for non-usage, i.e. if your workload remains idle, you’re not billed at all.

Highly available

The final differentiator that has made serverless computing so popular is its high availability.

Memory

Serverless offers no—or very small storage space, and it is temporary

Traffic

When traffic cannot be easily predicted, serverless is the better bet, as it scales up automatically and you only pay for what you use.

Amazon offers several serverless services, the most commonly used ones are Amazon DynamoDB, Amazon API Gateway, AWS Step Function, Amazon Simple Queue Service, and the crown jewel of AWS’s serverless offerings: AWS Lambda.

Key benefits of serverless computing

Containers

As its name implies, Containers are a kind of virtual box in which the code and all its dependencies, i.e. configuration, code, runtime engine, etc., are packed away. The most popular container form is called Docker. The advantage here is that since everything is contained in the package—i.e. the Docker container—you can run the application smoothly in any computing environment. Of course, the containers still have to be managed, i.e. aspects like deployment, networking, scaling, health monitoring, etc. must be managed. Losing a node or process, for example, can disrupt your service and cause downtime. It’s not possible to manually manage multiple containers; a problem that is solved by container orchestrators like Kubernetes, Amazon EKS, Amazon ECS, and Docker Swarm.

You can take a closer look at the differences between ECS, EKS, and Fargate, here.

What does a container contain?

Container management

Unlike serverless, where the CSP handles management tasks, with containers, since the user has full control of the underlying infrastructure—VM, OS, etc., it follows that any management and orchestration that needs to be done falls to the user.

It also means that you are free to install almost any software that you need—and perhaps the most attractive feature about containers is that you can use pre-packaged images that are already available. For instance, say you are developing an app in Java; you will need the Java software installed, some testing tools, etc. A container with all of this is already made available to you. You just need to pick it up and run it.

Compute power

Serverless lets you pick the compute power you need—from 128 MB to 3 Gigabytes, with a runtime time limit ranging from one second to 15 minutes.

Where containers are concerned, adjustment of your VM parameters needs to be done by you. Once your container is up and running, it can be tricky to change an EC2 instance type. Ideally, you need to plan for this beforehand.

Memory

Containers come with hard disks attached to the nodes

Use Cases

Serverless is well suited for event-driven architectures; it can be natively integrated with other cloud services, making it easy to trigger your Lambda instance when it is needed.

Containers excel when you need to run specific software; say you need to run a webserver or an app server, it is easy to install it in a container and run it. This is not possible serverless, simply because you have no access to the underlying infrastructure.

Traffic

Serverless are the definitive winner in use cases that see unpredictable traffic.

Conversely, containers are better suited to use cases where the traffic is predictable because you’re paying for the underlying instances, whether you use it or not. When containers scale the entire VM scales and when traffic increases beyond its capacity, it spins up another Kubernetes node—i.e. another EC2 instance—and even if this node is at just 50% utilization, you have to pay for the entire EC2, i.e. you’re paying for idle resources.

Cost Difference

The difference in cost incurred in Serverless and Containers can be best explained with a couple of use cases

Scenario 1

In the first case, let’s assume your traffic volume is three million a month, each execution consumes 512 MB of memory and takes 300ms. Let’s also assume that the traffic is completely unpredictable. Using the AWS-provided lambda calculator (you can try it out here), you will see that it costs just USD eight per month.

In this same use case the container configuration will cost as follows: US$144/month for the control plane; $14 for a small EC2 (t3), which will function as our worker node. This comes to around $160/month, and the cost will increase if there is a spike in traffic, which we have assumed is wildly unpredictable.

Scenario 2

In the second use case, let’s put the traffic volume at 90 million per month; memory @512 MB/execution, and 250 milliseconds per execution. Finally, let us assume that the traffic is pretty predictable.

The cost here comes to $206 for Lambda and with the same parameters the container cost will be as follows: $144/month for the control plane; $29/month for a t3 medium worker node, making it $173/month.

The above scenarios make one thing clear: there is no blanket winner, where cost is concerned. If the traffic is predictable, using containers allows you to select the right VM and CPU, making containers a better option in such cases.

Conclusion

In a nutshell, serverless services, like AWS Lambda allow you to run code, which meets high traffic demands at any time, without provisioning or managing servers. And, of course, you don’t pay for idle resources. However, if you need more control over the underlying environment, say access to a web server, and the traffic is quite predictable, containers are the way to go.

Are Serverless and Microservices Made for Each Other?

Wed, 12 Oct 2022 07:40:12 +0000

Serverless computing and microservices have a lot in common; both seriously disrupted computing as we know it, both offer excellent scalability, both are cloud based, both are modular in nature, and both help minimize overheads. So are they made for each other? Let’s take a closer look.

Serverless computing describes an approach that abstracts away the server infrastructure relieving developers of the necessity to provision, manage and secure the underlying infrastructure needed to execute code. Serverless computing is best applied in executing smaller segments of code, which are triggered by pre-set events. They are also modular in nature and easy to automatically scale, making them ideal for use in microservices based architecture.

Microservices architecture arose in response to the difficulty—and expense—in managing traditional monolithic applications, which are designed as one integrated and independent unit, i.e. database, client-side interface, and server-side interface all compacted in one unit. Monolithic applications are fairly rigid, making them difficult to scale, update, and manage, except as simple applications.

Unlike monolithic applications that are built as one integrated unit, microservices comprise smaller services—each handling only one service, managed independently, and individually scalable.

For a deeper understanding, read: Monolithic vs microservices: principles and practices

For instance: an eCommerce website built as a microservices application would contain individual microservices for aspects like product catalog, check out, shipping, et al. These microservices can be hosted on containers, VMs, or private clouds. Their modular nature makes them easy to scale horizontally; where, in the event of a peak, monolithic applications would have to be scaled up in entirety, in microservices-based applications, only the service that’s facing the rising demand can be scaled.

Serverless microservices: how it works

Since a microservice may comprise just one or two functions—that are concurrently deployed—each microservice can be broken down to individual functions and hosted on serverless. The serverless function will execute the corresponding code in response to a pre-set trigger: http request, file download or upload, or any other event.

Continuing the above example: when an order is ready to ship, it could trigger a function that checks and confirms the shipping address, this, in turn, could trigger another function that handles printing of a shipping label, and trigger another function, which could send a shipment notification to the intended recipient. This is a fairly simple explanation; in actual implementation one would add things like queues in between for fail safe and to manage the parallel processing limits of the serverless infra as well as the system needs.

Typical Serverless Microservice-based Architecture

Benefits of serverless microservices

Broadly, serverless microservices offer all the advantages that serverless architectures provide, such as:

Lower overheads, possibly lower than container based microservices.
Cost-efficiency—you avoid the cost of provisioning and managing underlying infrastructure, and only pay for what you actually use. i.e.only when the function is called.
Easy scalability—their modularity makes horizontal scaling simple
Manageability—thanks to their modularity
Flexibility: This means that functions used in one microservice can also be extended to other microservice—if it uses the same logic and components. This reduces the amount of code that would otherwise have needed to be written to scale out the application

Use Cases

Any evolving application, especially the complex ones, make good candidates for serverless microservices: their modularity makes them simpler to manage and scale.

If the application can be broken down into multiple, disparate services, and each, in turn, can be split into short, event-driven tasks. Applications that handle consistent loads (i.e. requiring them to be constantly ‘on and being used’, or those that handle long running tasks, would work better as monolithic applications.

Challenges

While serverless microservices allow quick and cost-effective iteration, they do pose a few challenges

Defining function boundaries. It’s important that each function has a limited role, but it’s not easy to define the scope of each function, furthermore stretching your logic across too many functions makes it harder to add updates or add new features.
Cold starts. When and if a function is triggered after a period of inactivity, it can cause higher latency. This can be resolved by keeping those functions ‘warm’. This can raise costs but, depending on the application, can still be more cost effective than a monolithic approach
Complex troubleshooting. One application typically comprises multiple microservices, each of which use functions that are short liven and shares with other resources. This complexity makes it difficult to understand dependencies and trace root cause of errors is they arise.

These challenges can be resolved by a) keeping the occasionally needed functions in a warm mode—for instance, the service handling sign-in or account creation, and b) by migrating to serverless in reverse-priority, i.e. moving non-critical microservices to serverless first.

In a nutshell

Serverless microservices refers to cloud-based services that use serverless functions to perform specific tasks within an application. Serverless functions are modular and, thus, easily scalable, rendering them ideal for microservices-based architecture. This approach combines the benefits of serverless computing and microservices architectures, enabling lower costs, lower downtime, higher scalability, and independent deployment. As with any computing technology, serverless microservices is not a one-size-fits-all solution. Simpler applications, and those with long running services, are more suited for a monolithic design.

Book a free 30 minutes consultation call

The Problem with Microservices

Fri, 30 Sep 2022 09:42:47 +0000

‘Small size’ may be one of its key principles, but microservices are regularly touted as the next big thing, and in a sense, they have disrupted the way we look at application development. To reiterate, the advantages to using the microservices architecture can be listed as follows:

Microservices benefits

Enhanced dynamic horizontal scaling with ease
Improved Management
Autonomy—in choice of technology, language, et al.
Agility
Speedy delivery and deployment—including debugging

Microservices are build for autonomy, specialization, and scalability

For a deeper dive into the microservice architecture, read our article: Understanding Microservices

By design, microservices offer multiple benefits in developing and deploying applications for businesses, and they are surely a big step forward in adopting DevOps as a culture. But that doesn’t make them a silver bullet for all development problems. The benefits above have made microservices the go-to choice for businesses revamping legacy applications. But there are many instances when microservices are not just less-than-ideal, they can be downright counterproductive. Let’s take a closer look…

Challenges to Using Microservices Architectures

1. Deployment Design

Unlike monolithic applications, microservice applications are complex in design, for a number of reasons, such as

Identifying boundaries and connection points between microservices
Determining size
Designing a suitable framework to integrate services
Microservices need to be created within a bounded context, i.e. each microservice must clarify, encapsulate, and accomplish a specific task. This requires each function to be developed with a data-centric view, and this brings its own challenges, because, without the proper logic, the data would be illogical.

2. Security

Because microservices are deployed across servers and cloud environments, there is a greater risk of loss of visibility of application components and loss of control. Not only does this result in additional points of vulnerability, but it is also harder to test integration tests for these vulnerabilities as each microservice communicates with other microservices via different infrastructure layers.

Since data within a microservice framework is distributed, it is tricky to maintain confidentiality of the data. Setting up access controls and administering secure authentication to access individual services is a technical challenge and also increases the surface exposed to attacks.

3. Testing

Since microservices are designed to be independent, each service must be tested individually in isolation, complicating the testing phase of the software development lifecycle (SDLC). The need to consider integrated services and their own interdependencies further complicates this complexity. This increases the integration test time.

4. Operational complexity

Another principle of microservice that brings challenges is the freedom to choose the technology for each microservice. This in itself can make it difficult to maintain operations, in the following ways:

Monitoring challenges: Traditional monitoring isn’t suitable for microservices for one big reason: a request from the user interface has to travel a convoluted path or multiple services before reaching the one needed to fulfill its request. Without the appropriate tools, it is well nigh impossible to identify the cause of any issue.

Complexity in Application Performance Monitoring

Scalability challenges. Microservices frameworks break an application down into smaller interdependent services that are hosted on separate servers. This means several individual components have to be coordinated when scaling in the event of a spike in usage.

5. Communication

Microservices are, in a sense, miniature standalone applications that communicate with each other to fulfill a set objective. This means microservices have to be configured with infrastructure layers that allow resource sharing across services. This is a challenge because improper configuration will lead to increased latency and reduced speed of calls to discrete services. i.e. slow response time.

Complexity and improper configuration increases latency in microservices

When to Avoid Using Microservices

There are three basic situations that one should consider when considering the viability of using microservices or skipping the microservices architecture for a given application.

Undecided domain

Microservices are created within a bounded context. Thus, if it is complex to break down business requirements into specific domains, it will be just as complicated to create optimally sized microservices. This will also bring the challenge of configuring communication between various services. The more complicated it gets, the more difficult to realize real value in the microservices architecture. As the application evolves in the future, it is even more unlikely that your application’s domain will remain unchanged.

Inability to embrace a DevOps culture

One of the big reasons for adopting microservices is the ability to transition to a DevOps culture; the benefits are obvious:

Automation

Reduced cost & effort

Operational efficiency

If transitioning to a microservices architecture will not help achieve these goals, it is better to reconsider adoption. There is no point to add complexity and effort without gaining significant efficiency.

Small application size

If the application is small and the size doesn’t justify splitting into smaller components, skip the microservices architecture. Applications that are already small don’t need to be broken down into smaller components. The very objective of microservices architectures is to break large, complex applications into a loosely coupled application of smaller services. If the application is already small and straightforward, transitioning to a microservices framework will bring unnecessary complexity.

Should You Adopt Microservices?

There is little doubt that the microservice architecture provides a number of benefits, including faster delivery, better software quality, scalability, autonomy, etc. Businesses considering transitioning from a monolithic model to microservices need to conduct careful due diligence to ensure that their objectives will be served. It goes without saying that if the downsides of using microservices outweigh the benefits—factoring in time, effort, and money spent—then microservices are most likely not the ideal solution for the application.

*Still Undecided? *Reach out to our experts to explore whether microservices can be the solution to your needs

Monolithic vs Microservices – Principles and Practices

Fri, 16 Sep 2022 11:23:54 +0000

Remember the old black and white flicks where the computer was depicted as a massive machine, usually in the basement, all whirring wheels and blinking lights? Well, those old movies had the size right. Back in those days, we’re talking about the 1980’s here, before computing began to go mainstream, monolithic applications lived on mainframe computers. Then, only organizations with deep pockets could afford these computers. This did give them some advantage but it didn’t come cheap, nor was it particularly speedy, as it often took hours to receive the output of a program. And if the program had a bug, the user would know about it only after a couple of hours. And only after the required corrections would be made, would the computer churn out output.

Those applications integrated everything—including the hardware. UI, business logic, utility programs, and even the database were totally integrated into the application itself. The reason it was so inefficient was that the entire hardware and software were shared by multiple users and background processes.

These applications were the forerunners of present-day monolithic applications, and the inefficiencies drove the creation of microservices architecture. To understand microservices and how they have disrupted IT, we need to understand the differences between each and what led to the move from monolithic to microservices.

Monolithic applications

When the functionalities of a project are integrated into a single codebase, that application can be described as a monolithic application. The clue is in the name itself: *mono, *meaning single (in this case, a single codebase, which contains all the required functionalities for the app to run) Typically, the application is designed with various layers like presentation, service, and persistence and then deployed with the codebase as a single jar/war/lib/binary file. So far so good? Well, not really. There are several disadvantages to this type of application, as listed here:

Disadvantages of Monolithic applications

As organizations grow and their needs evolve, the application becomes too large and complex, making it difficult to manage.

If a single small change needs to be made, the whole application must be retested and redeployed.

With the increase in functionality and size, the application’s start-up and deployment time also increases.

It is very difficult for a new developer (even if his responsibility is related to a single functionality) to understand the logic of a large Monolithic application.

Horizontal scaling is not feasible, as multiple instances of the entire application have to be deployed is a single part of the application encounters large load/traffic. This is very inefficient and resource-intensive.

If, for instance, there is some new technology that is well suited for a particular functionality, it is, nevertheless, difficult to employ, as it affects the entire application, both in terms of time and cost.

Monolithic applications can be unreliable as even a single bug in a single module can bring down the entire application.

But it’s not all doom and gloom. Monolithic applications do have several advantages, which is probably why they are still used.

Easy/straightforward development (compared to microservices)

Easier to deploy, since it uses one single codebase, viz. only a single jar/war/binary file needs to be deployed.

Fewer problems of latency, as all the functionalities exist in one place

Better security (in comparison to microservices), as the application parts are all in a single place.

The disadvantages of monolithic applications led developers to split the services that were integrated into one codebase. This allowed easier scaling and deployment. This type of architecture, which became quite popular in the early 2000’s came to be known as Service Oriented Architecture (SOA).

Service Oriented Architecture

In an SOA, the large application is broken up into multiple smaller services, which are deployed separately. These applications follow a principle known as loose coupling, i.e. the design ensures minimum dependency on each other. This allows services to be used at a specific capacity even if one of the dependent elements goes down.

While the reusable components are a time saver in the development process, it also means that if one component does down, all the systems that use that component will also fail. This is a big point of difference between SOA and microservices. An SOA system handles multiple tasks, whereas each microservice is responsible for only one single task (aka, single responsibility principle). Furthermore, SOA services don’t communicate with each other directly, they used an Enterprise Service Bus (ESB). It is possible to do away with the ESB and have the services communicate directly but this can complicate the development process and raise costs, too.

So, while SOA resolved some challenges posed by the monolithic approach, deployment, updates, scaling, etc. were still an issue. This led to the evolution of the microservice architecture.

SOA vs Microservices: High Level DifferencesSOAMicroservices Each system can handle multiple tasksSingle responsibility principleNot as scalable as microservicesHighly scalable and flexiblePrimarily about resource sharingThe primary purpose is to exclude all dependenciesLoosely coupled (compared to monolithic apps)Significantly more loosely coupled than SOA

The biggest noticeable difference between monolithic applications, SOA, and microservices is the uncoupling of services. Although this is true for SOA as well, microservices are far more loosely coupled than SOA applications, because each microservice is responsible for just one specific task. This is possible, in large part, because each microservice has its own database, unlike monolithic or SOA architectures where databases are shared.

Having discrete databases does lead to some duplication of data, but having a database per microservice ensures loose coupling. Furthermore, since microservices each have their own separate database, they can use the type of database that best suits each one’s needs.

Principles of microservices

Single responsibility: This is one of microservices’ design’s basic principles, wherein each microservice has one and only one responsibility or functionality. In other words, the number of microservices that each application should comprise is equal to the number of functionalities needed.
Decentralized database: As described earlier, this is necessary for each microservice to function independently.
Diverse tech-stack: Given the abundance and diversity of technologies in today’s world, there is always a technology that is best suited to implement a particular functionality, and microservices architectures leverage this to the fullest, allowing developers considerable autonomy if choosing preferred technologies. This was not possible in monolithic applications, and led to compromises, as developers were not able to use different technology for each functionality.

Microservices, on the other hand, are never restricted from adopting the best-fit technology stack or backend database storage to meet the business’s requirements.

Designed for failure: Microservices, ideally, should be designed in a manner where the failure of one does not affect the whole system, or indeed, any other microservice. This was not the case in the Monolithic applications, where the failure of one module inevitably led to the whole application failing.

Microservices advantages

Easy to manage a specific micro-service, given its smaller size
Easy to deploy The entire application doesn’t need to be stopped to deploy an update in one of the microservices; only that particular microservice needs to be redeployed and that too with zero downtime.
Easy to onboard a new developer, as he doesn’t need to understand the whole system, the microservice providing the functionality he is responsible for.
Easy to scale When and if a particular service is facing a heavy load, only that particular microservice needs to be scaled…for instance, shopping carts experience far more loads than say user registration. In this instance, only the microservices responsible for shopping carts need to be scaled. In other words, the microservices architecture supports horizontal scaling.
Freedom to use best-fit tech-stack Since each microservice has a particular function, and the microservice is basically designed for autonomy, there is no restriction on adopting the technology that best addresses the business requirements.
Easy to debug In the event a bug infects the application, just that particular microservice goes down and can be individually addressed. It doesn’t affect other microservices as they continue to provide other functionalities, ensuring the system doesn’t go down as a whole.

Disadvantages of microservices

While there are many clear advantages to using microservices, there are some downsides too.

Increased complexity: As a distributed system, microservices are much more complex than monolithic applications. And this complexity increases as the number of microservices within the application increase.
Specific skill sets: Developers working on microservices architecture must have special skill-sets, such as being able to to identify microservices and manage their inter-communications.
Debugging a microservice is easier: in theory, it can be complicated in practice, as the control flows over many microservices, and pinpointing why and where exactly the error occurred can be a tedious task.
High network demands & increased latency: microservices’ network usage is costly, as the microservices need to interact with each other and all these remotes bring network latency.

Less secure (compared to monolithic applications) because of inter-services communication over the network.

Conclusion

It’s never simple to build any application, and the complexity increases as the application grows larger or more evolved. Monolithic architectures are thus better suited for simple, lightweight applications, while microservices architectures are a better choice for complex, evolving applications. Some experts are of the opinion that it is more logical to start with the monolithic application first; while others recommend going directly with a microservices approach if that is indeed your goal. Whatever the case, it is important to understand the principles governing monolithic architecture as it is the starting point for microservices architecture.

Book a free 30 minutes consultation call

Components of a Microservices Architecture

Tue, 13 Sep 2022 11:45:13 +0000

As one might guess from its name, microservices describe an architecture that is small. It manages this by breaking up large monolithic applications into individual, and independent services that are managed by discrete teams. Each service includes all the elements it needs to run in any environment, including code, databases, application functions, and programming logic, and spreads it across servers and platforms.

To do all this effectively, the microservices architecture requires certain components that help bring all these entities together cohesively across a distributed system. The most important of these components are as follows:

Containers

Although this might sound paradoxical, containers are actually not necessary for deploying microservices; nor are microservices the only reason containers exist. What makes them vital is that they have the ability to significantly improve deployment, save time, and enhance app efficiency, compared to other deployment methods such as Virtual Machines (VM)

The biggest point of differentiation between containers and VMs is that a VM needs a dedicated Operating System (OS) for its use, whereas many containers can share an OS and middleware components. Eliminating VMs eliminates the need to provide individual OS for each small service. This means organizations can run a larger collection of microservices on a server.

The second significant advantage of using containers in microservices is that they offer the ability to on-demand deployment, without compromising application performance.

Containers orchestration can also be automated, this enables configuring, scheduling, management, provisioning, deployment, scaling, and health monitoring of individual containers to be undertaken with minimal effort. There are several container orchestration tools; the most popular of which are Docker (aka, Docker Swarm), an open-source platform for container management, Kubernetes, OpenShift, and Google Container Engine (GKE), among others.

Containers in microservices, thus, enable independence and consistency, which is a critical part of scaling pieces of a microservices architecture — depending on workloads — as opposed to the whole application. In the event of a failure, containers support the ability to redeploy microservices.

Service Discovery (Service Registry)

Unlike in a monolithic application, microservices architectures comprise several smaller applications that work individually to deliver a collectively larger solution. This allows for many big benefits, including rapid and economical scaling—since only individual microservices need to be scaled rather than the entire application itself—quick deployment, monitoring, etc. But to function, the microservices that comprise this architecture must be able to communicate; i.e. call on other microservices as needed. This means they must know where the particular service is deployed. Enter, Service Discovery! Service Discovery is a microservice in itself, and its function is to maintain a register (service registry) of where all the microservices are located. So in one sense, this is actually a service location discovery.

Service discovery patterns

There are two basic discovery patterns: the client-side pattern and the server-side pattern

The client-side discovery pattern: Consider an analogy here. Say you want to order out from a certain restaurant but don’t know their number. So you call up directory services (or Google), get the number, and make the call. In this instance directory services (or Google) acts as the service registry, and you are the client. This is known as client-side discovery. The pattern basically searches the service registry to locate the required service, sends the information back to the client service, and then routes the request from the client to the required service, maybe, using a load balancing algorithm.

The server-side pattern: In a server-side discovery pattern, using the above analogy, you—the client—call up Google, which searches the service registry AND forwards your request directly to the applicable service instance.

It is important that the service registry data should always be current, in order for services to find their related service instances at runtime. If the service registry is down, the entire inter-service communication will crash and so with the app. To avoid this, enterprises typically use a distributed database.

Service Mesh

As microservices grow in features and maturity, they also grow in complexity, with more and more microservices ‘talking’ to each other to deliver a cohesive user experience. But this also means there are many more endpoints and interactions to monitor, secure, and scale. This translates into increased security vulnerability with higher debugging effort and time. Service Mesh addresses this need. Acting at the application level, the service mesh handles service-to-service communication for cloud applications. It overlays existing applications, without them needing to be aware of its existence. It comprises a Data Plane and a Control Plane. The data plane attaches small proxies to each service, these are called sidecars and their job is to handle incoming and outgoing traffic between services.

The control plane manages service-to-service communications, security policies, and monitoring.

The control plane manages and configures proxies to route traffic, and also collects telemetry data to help monitoring

Service meshes eliminate a lot of the manual effort needed for services to interact. As your applications continue to grow, meshes work to maintain infrastructure and ensure that communication doesn’t break down. This makes it easier for DevOps teams to manage Cloud Native Applications (CNA) in hybrid or multi-cloud environments.

Service meshes contain the logic governing communications. Since the logic is in individual services, it increases the portability of individual microservices. They can be moved to a new server, Docker/K9 cluster or a different public cloud platform, without needing to rebuild the application.

By enforcing security policies and managing access (with encryption, where required) and authentication across the environment, service meshes reduce the potential for cyber attacks.

Read also, Monolithic vs microservices architecture (link to article #3)

API Gateway

Microservices are disconnected autonomous services that together make up the entire application (unlike a monolithic app). This means that to deliver the desired user experience the services need to communicate with the outside client, and occasionally with each other. And they do that through an API gateway. API gateways create an abstraction layer between microservices and outside clients.

The API gateway’s main functions center around communication and administrative roles—such as authenticating, caching, and managing requests, as well as monitoring, messaging and even performing load balancing (which typically occurs within a monolithic application). Thus API gateways allow microservices to remain lightweight.

Since services are autonomous they are basically polyglots, in that they are free to use different technology stacks. An API gateway synergizes this by standardizing messaging protocols, thus speeding up communication between microservices and clients and freeing both the client and the service from the task of translating requests written in unfamiliar formats.

In addition, most API gateways also provide built-in security features, which allow them to manage authorization and authentication for microservices, as well as tracking incoming and outgoing requests to identify any possible intrusions.

There are many API gateway options—both open source and proprietary, e.g. from cloud providers such as Azure and AWS—available to choose from.

Applied AI offers an easy-to-use Serverless API generator that comes with clear instructions to set up, configure and secure. The SLS API Generator can be used with a CLI-based approach, or an API-based approach, which enables configuration and development of APIs without the time- and effort-intensive task of writing production code for the API.

Benefits include:

Speedy development/integration

Ease in modifying code, as per entity definition

Use of pre-written test cases to save unit testing time

Code uniformity, standardization (standard libraries)

Lean code that conforms to DRY norms, and coding best practices

For step by step instructions on how to set up, configure and secure your API gateway using the SLP API generator, reach out to our team, today.

Understanding Microservices

Wed, 07 Sep 2022 11:30:30 +0000

A microservice architecture describes an application that is a collection of smaller autonomous, loosely coupled services, which can be managed, maintained, and tested by a small team. This makes it possible for developers to make changes to a service and redeploy it without affecting the entire application. It also allows developers to work in a variety of programming languages—as each service is discrete and interacts with the other services through APIs.

But things weren’t always so easy…

Traditionally, developers built software applications as a unified structure that was self-contained; a single computing network with a single codebase that integrated myriad smaller applications. This was an easy and convenient build, and still is, especially during the initial stages of a project’s life cycle. It allows easier code management, and deployment. It enables a higher speed of development as a result of the simplicity that comes from utilizing one single code base. This led to monolithic architecture becoming the norm. The problems began when applications grew to a size that complicated scaling. Making any change to an application of this size called for the entire stack to be completely updated. To make a single change to a single function called for the stopping of the entire program as developers updated the function and tested it. Developers were forced to build a similar but updated version of the application. This was time-consuming, and resource-intensive and it made deployment a challenge.

Clearly, a disruption was needed.

Disadvantages of a Monolithic Architecture

Slow development speed: The size of a monolithic application hampers development, increases complexity, and slows down the entire development and release process. This makes it complicated, time-intensive, and expensive to implement new features and functions

The key disadvantages can be summarized as follows:

Scalability: Individual components cannot be scaled; the entire structure has to be scaled up, which is an added cost factor.

Reliability: An error in any module impacts the entire application.

Time to release: Any small change would need a complete regression cycle would mean increased time to test and so to release.

Deployment: Any change, no matter how small, requires the redeployment of the entire monolithic application.

Disrupting the Monolith Approach

Then in 2009, a large and growing OTT streaming company did something revolutionary. In a bid to meet the demand for the explosive growth of its video streaming services, the company migrated its entire IT to a public cloud and switched from its monolithic architecture to a structure where services were broken up into smaller individual and autonomous components. In effect, microservices. This was even before the term ‘microservices’ came into being.

That company was Netflix.

Netflix now has thousands of microservices that manage and support separate parts of its platform. And Netflix’s engineers deploy code frequently, possibly a thousand times a day. This just would not have been possible with the earlier monolithic build.

Advantage: Microservices

To repeat, the microservices architecture, (or simply, microservices) relies on a series of independently testable and deployable services. Each of the services points to a specific purpose or goal. They have their own business logic and database. When needed, updates, tests, scaling, and deployment happen within each service.

By decoupling major business applications into separate, independent code bases, Microservices makes it easier to manage.

It must be pointed out that Microservices don’t actually reduce complexity. What they do *do *is make complexity more manageable by splitting tasks into smaller processes that function independently of each other, while continuing to contribute to the overall whole.

This is a huge advantage for DevOps too, as the continuous delivery practice that defines DevOps, aligns with the discrete, de-coupled, autonomous nature of a microservices architecture, allowing teams to adapt quickly to user requirements. In addition, microservices enable a continuous integration and continuous delivery (CI/CD) approach, as developers can now experiment with code and quickly roll changes back if they don’t work as intended.

Microservices resolve a variety of headaches for businesses. Since each of the microservices units run independently, they can be developed, updated, deployed, and scaled without impacting the other services. This also means avoiding duplicate functionality development across the org, other groups and orgs can just use the required microservice. It enables more frequent software updates and improves reliability, uptime, and performance. From deploying updates weekly or even longer, they can now be done multiple times a day. This allows companies to deliver greater value to their customers, faster, and more cost-effectively.

Building robust inter-microservices communicability

For a microservices architecture to function optimally, individual services need to communicate with each other. APIs enable this communication, without it we would just have a collection of disconnected microservices. The alternative is to use a direct client to microservice communication approach. Here, each microservice would have a public endpoint—which would otherwise reside on the API. This would allow a client application to send its requests directly to a particular microservice. This approach might work for a small microservices application, but with large, complex microservices-based architectures, there are some issues that might occur, such as increased latency and complexity, cross-cutting concerns, inability to communicate with services that use non-Internet protocols (like AMQP, or binary).

In such instances, API gateways offer a more functional solution for large or complex applications. It provides a single entry point (aka, backend for frontend). The gateway offers an intermediate layer that makes it convenient for microservice-based application connectivity, avoiding issues such as

coupling (where client apps are coupled to microservices)
multiple round trips (increased latency)
security issues (without a gateway the microservices will be exposed, offering a larger vulnerable surface); cross cutting.

SLS API Generator

Applied AI uses SLS API Generator to enable configuration and development of microservices APIs without the tedium of writing production code for the API, using Dont Repeat Yourself (DRY) patterns. The tool can generate serverless code along with unit test cases as well as CI/CD pipeline —as per your entity definition.. The generated code can be modified by users as per their business logic and then deployed using the generated pipeline.

SLS API Generator Benefits

Speedy development of new services for the entity
Ease in modifying code, as per business logic
Use of pre-written test cases to save unit testing time
Code uniformity, standardization (use of standard libraries)
Lean code that conforms to DRY norms, and coding best practices

*Usage of the SLS API Generator is an important differentiator which helps us to develop production quality serverless APIs for you quickly. Post the Entity/Object Model design it takes us just days to get those APIs deployed with a very good unit-test coverage. *

Also read: Components of a microservices architecture

Microservices Advantages

Agility: Small, independent teams can build and deploy quickly and frequently, which promotes agility.

Flexible scaling: Like a monolithic application, microservices too can reach load capacity. The difference is that when and if this happens new instances of that service can be deployed quickly, relieving pressure. As a multi-tenant and stateless entity with customers spread across multiple instances, it can support significantly larger instances.

Continuous deployment: Release cycles are now faster and more frequent. Updates can happen multiple times a day, instead of weekly or longer. Very good test coverage improves this speed further.

Highly maintainable and testable: Being able to experiment with new features, and roll back if they don’t perform as intended, makes it easier to update code, isolate bugs and fix them. And it reduces time-to-market for new features.

Independently deployable: As microservices are individual (independent) units they can be quickly deployed.

Technology flexibility: The autonomy and independent nature of microservice architectures gives teams the freedom to select the tools they desire.

High reliability. Changes can be made to a specific service without bringing down the entire application.

All these advantages do not make microservices the ideal one-size-fits-all solution. Not all organizations can—or should—implement microservices. Moving from the monolithic architecture’s one, or a small number of codebases microservices, which require many more distributed systems and services, can give rise to unintended complexity, and can reduce the speed and flexibility that microservices were designed to deliver. Plus, it can be a challenge to determine how the application’s sub-services should be split, how different components relate to each other, who owns a particular software component, etc.

Thus, smaller companies—a single product company, for instance—would not need a microservices architecture at all.

Typical Disadvantages

Development sprawl: Compared to monolithic services, microservices add complexity, as there are more services in more places created by multiple teams. This results in slower development speed and sub-optimal operational performance.

Higher infrastructure costs: Every new microservice comes with its own set of requirements, such as test suite/s, deployment playbooks, hosting infrastructure, monitoring tools, etc., which can bring up costs significantly. (Going serverless would help immensely in this though).

Organizational challenges: Development teams need to communicate, and collaborate to effectively coordinate updates, which adds another level of communication.

Debugging challenges: Every microservice has its own logs. This makes debugging more complicated. Plus, if a single business process runs across multiple machines, debugging will be further complicated.

Lack of standardization: Autonomy is good, but it can also lead to a proliferation of languages, logging standards, and monitoring.

Lack of clear ownership: The addition of more services will also increase the number of teams running those services. At times it can become difficult to identify the available services a team can leverage or whom to contact for support.

Recognizing the Need to Migrate to a Microservices Architecture

Most projects initially start out as monolithic and over time, as new features are added, evolve into a microservice architecture.

When this happens it may start to become cumbersome to have many developers working on a single codebase.

Code conflicts will also arise more frequently; plus there is a greater risk of updates to one feature introducing bugs in an unrelated feature.

When and if you notice these undesirable patterns, it might be time for your company to consider migrating to microservices.

Unsure if and how your organization can benefit from microservices? Reach out to our team for a no-commitment presentation, at your convenience.

Book a free 30 minutes consultation call

Containerization Experts Increased Developer Velocity by Reducing 50% Scrum Time

Wed, 17 Aug 2022 12:17:07 +0000

Developers who were spending more time on container-related issues are now able to focus on Application Features

Table of Content

Introduction
How we Accelerated Dev Productivity by Providing Ops Support for Kubernetes
Questions You Should Ask Before Initiating Your Containerization Journey
Key Benefits of Containers & Containerization for Businesses
Microservices – Standardization and Technology Infrastructure
Security-oriented DevOps mindset
Specific Containerization Challenges Our Client was Facing And How we Resolved Them
Three main reasons for Container-related Issues
Secrets of our Containerization Expertise
Gene Kim – Amplify DevOps Success with Containers

Introduction

In this article, you’ll learn how we helped an identity management firm save more than half of their scrum time and focus more on their development features.

Plus, our Secrets as a Containerization Experts!

You will also get to know some basics, while we share techniques to embark on your containerization journey with a leading orchestrator –“Kubernetes”.

Before that, let’s face this!

Over the last few years, the container space has exploded in popularity.

Kubernetes and Docker have ascended to the ranks of the most popular technologies in the tech world.

And while developers have adopted containers to increase reliability and scalability. There are many unspoken reality checks.

Let’s see a real-world example,

And understand that even if you started out with a “container-first” approach, what might hold you back.

And how taking assistance from containerization experts can boost your developer’s velocity.

It’s time to get some background.

Increase your Developer’s productivity by 96.5% with DevOps-in-a-box

How we Accelerated Dev Productivity by Providing Ops Support for Kubernetes

A leading Identity management firm from Bengaluru has started its containerization journey with the intention to achieve isolation, security, agility, and portability in its development.

But soon things started to change.

Their teams started spending more time on container-related issues than focusing on the features itself.

You might be wondering how come a secure and agile solution started becoming a bottleneck for them!

Well, let’s look at the below 2 questions to understand the answer:

1.) Before adopting the “container-first” approach, Have you done some research on the key aspects of the application containerization journey?

Are you equipped with the right expertise to manage containers, not just create them?

Here, to give you a brief on the containerization journey that comprises three major stages:

And below is the question list you should consider.

Questions You Should Ask Before Initiating Your Containerization Journey

Are there any applications in the business portfolio that can be containerized?
Which container platform serves best for your enterprise?
Is it worth containerizing all the applications?
What extensions will you need in the container platform to accommodate the applications?
What will the upskill path be for developers?
Will the containerized applications be able to meet existing Service Level Agreements (SLAs)?

And as you can see, we have our own set of questions during the evaluation process. I.e:

Is the app pre-packaged as a single binary or jar file?
Is the platform on which your app is built available in a containerized version or package yet?
Are any of your 3rd party apps available in a container version yet?
Is the app stateless?
Is your application already part of the continuous integration, continuous deployment pipeline yet?

Answers to these questions help us better strategize steps for you.

Would you like to explore our DevOps services along with the toolkit expertise? Click here

To those who don’t have a clear idea of why businesses choose containerization, here is a quick brief:

Containers allow numerous apps to run on a single virtual machine (VM), reducing the number of software licenses required for an enterprise organization to develop in a container environment.

And how do they accomplish this?

They do this by sharing OS kernels, instead of requiring their own.

That further makes containerization a more resourceful approach, both financially and computationally, to enterprise software development.

So, keeping that in mind, businesses see the following key benefits that come with Containerization.

Key Benefits of Containers & Containerization for Businesses

Faster startup times
Less redundancy
Improved security
Better resource distribution
less space requirement, usually measured in MB rather than GB
Consumption of minimal amount of resources.

However, the bigger purpose of businesses today is to move to microservices based architecture to achieve the desired scalability in their applications.

Let’s take a closer look at the microservices and how Containers and Kubernetes are at the core of them.

Microservices – Standardization and Technology Infrastructure

Microservices have become a popular architectural pattern in the last decade or so.

A key part of this evolution has been the use of containers and container orchestration tools like Docker and Kubernetes.

Need not to mention that with microservices, we divide a large application into smaller units that can be released separately. That gives businesses an edge to innovate continuously.

And when we look at the core of the microservices architecture then 2 very crucial aspects come to light:

Standardization
Technology Infrastructure

That’s where docke r and kubernetes come in.

Docker enables standardization!

It does not matter which language you use to develop your microservice whether it’s java or python you can create a docker image and you can treat that the same way.

This standardization also applies when it comes to observability.

And Kubernetes enables the technology infrastructure that is needed to run your microservices.

So, whether you need a naming server or a service registry, Kubernetes has such features built in.

Do you seek AWS partners? Our AWS experts have assisted numerous businesses in scaling their operations. Explore here

Security-oriented DevOps mindset

Let’s say, you are an enterprise and want to switch from VMs to using containers to host your application code.

Because containers can be deployed almost anywhere, they allow you to streamline the application development workflow.

However, The flexibility of being able to deploy virtually anywhere brings attack services around your container environment.

These include the images you use to build your containers, the image registries we use to store our images, and our container run times.

Also, the orchestration platforms like Kubernetes which we use to manage the lifecycle of multiple containers.

However, by prioritizing releases and new features, security measures often lack.

But this is where we at Applied AI Consulting practices the DevOps mindset with the focus on securities.

Our DevOps experts integrate security objectives into continuous delivery processes that reduce the setbacks you might face in future.

As a result, the amount of time spent on resolving security issues has been halved.

Additionally, we have reduced cost by 40% and achieved 90% automation with AI-powered testing and pre-designed pipeline.

Now, going back to our original story. The Identity management firm reached out to us through a reference from an existing client.

And because they have already been introduced to our DevOps expertise as well as our certified Kubernetes team.

They were confident that we could assist them in making things right with our containerization expertise.

We worked with them, understood their containerization-related issues, and resolved them.

Specific Containerization Challenges Our Client was Facing And How we Resolved Them

With Our Kubernetes Expert Solution

Now, the question arises why did our client get stuck in the above challenges?

Well, there are 3 key reasons for that.

The application container was not set up in the right way.
The utilities were not available – to read the logs, start the container, report the container, etc.
The focus on feature delivery is so high that there was no pressure on solving container problems which is usually not the true skill of many teams.

You have come a long way, and

It’s high time to reveal the Secrets of our Containerization Expertise

We have certified Kubernetes administrator and application developer with amazing detail-oriented skills.
We take prime attention while setting permissions, limiting resources, and monitoring systems that help us build a differentiated strategy.
We optimize the builds for the build cache that speeds up the workflow

Check out our Success Stories to learn more about the numerous ways we assist businesses.

Gene Kim – Amplify DevOps Success with Containers

As per Gene, Containers are kind of a technical miracle. He shares how containers can decrease lead times and increase feedback to developers.

A senior director of engineering was facing a biggest problem in her recent project, let’s call it X.

So whenever a developer made a code change to X it would require spinning up 45 VMs, and it would take 30 minutes to get the X instance running.

Then they moved on to a project that essentially put the entire X instance into containers so that they could run them on every dev laptop.

After that, whenever they made a change it would take about five minutes to get the new instance running.

Quality went up, lead time went down, and the developers were finding issues faster and fixing them faster.

You couldn’t do that before containers.

This is all from our end today to help you educate and innovate through containers.

And if you are embarking on the containerization journey we can help you do it right for the first time.

Furthermore, If you are facing similar issues we shared above, reach out to us at vijayroy@appliedaiconsulting.com

S.NoChallengeSolution1The client is having separate K8s clusters for the different development teams and each team develops the microservice as per their requirement but database structure is common for all the teams. If there are database changes done by the developers on the individual clusters but those changes are creating the application breakdown then they have to reset the database.

We reset the database to reference DB using an automated pipeline.2Again, because database structure is common for all the teams. If one team has made some changes in the database and those changes are required by other teams then they have to migrate the entire DB from one cluster to another.

Build a pipeline to Migrate the database from one cluster to another.3Different teams require fresh clusters for testing the application so they have to create the ad-hoc clusters.

Created an automated pipeline for EKS cluster creation and deployment of required microservices on those clusters.

4Initially, secrets were deployed using shell script but it was very difficult to maintain so there was a need for an automated pipeline.

Deployed the secrets using an automated pipeline.5The development team requires a centralized log for identifying the bugs and errors.

Used fluentd to send the application logs to a centralized location and display the logs on the application page so that the development team can see the issues/errors.6Analysis of memory utilization for performance testing.

Created heapdump for the running pod using an automated pipeline.7Checking different metrics from performance testing is important so we have to set up this.

Integrated prometheus and grafana for monitoring the different metrics for performance testing.8Pods were getting restarted due to improper memory assignment.

Fixed the restart issues of the pods by optimizing the memory requirement.9

As the client is having many clusters so monitoring the individual cluster is a very challenging task.Installed botkube for monitoring of the cluster and timely notification on the slack.10Application scalability and cost optimization were important for the application.

Implemented Kubernetes horizontal pod autoscaling (hpa) and autoscaler for the cluster so that all the requests are processed without any issue.

11The client was getting a docker pull rate limit error as they were using community edition.

Enabled Gitlab dependecy proxy pull through the cache to avoid the docker pull rate limit issue.

Now, the question arises why did our client get stuck in the above challenges?

Well, there are 3 key reasons for that.

The application container was not set up in the right way.
The utilities were not available – to read the logs, start the container, report the container, etc.
The focus on feature delivery is so high that there was no pressure on solving container problems which is usually not the true skill of many teams.

You have come a long way, and

It’s high time to reveal the Secrets of our Containerization Expertise

We have certified Kubernetes administrator and application developer with amazing detail-oriented skills.
We take prime attention while setting permissions, limiting resources, and monitoring systems that help us build a differentiated strategy.
We optimize the builds for the build cache that speeds up the workflow

Check out our Success Stories to learn more about the numerous ways we assist businesses.

Gene Kim – Amplify DevOps Success with Containers

As per Gene, Containers are kind of a technical miracle. He shares how containers can decrease lead times and increase feedback to developers.

A senior director of engineering was facing a biggest problem in her recent project, let’s call it X.

So whenever a developer made a code change to X it would require spinning up 45 VMs, and it would take 30 minutes to get the X instance running.

Then they moved on to a project that essentially put the entire X instance into containers so that they could run them on every dev laptop.

After that, whenever they made a change it would take about five minutes to get the new instance running.

Quality went up, lead time went down, and the developers were finding issues faster and fixing them faster.

You couldn’t do that before containers.

This is all from our end today to help you educate and innovate through containers.

And if you are embarking on the containerization journey we can help you do it right for the first time.

Furthermore, If you are facing similar issues we shared above, reach out to us at vijayroy@appliedaiconsulting.com

How to Create an API-Based Integration Gateway Utilizing the AWS Platform

Wed, 17 Aug 2022 11:53:48 +0000

If your platform provides an integrated payment solution. And for each individual client, if you are building and maintaining point-to-point integration then this blog is a must-read for you.

We had a client who was spending ~8 weeks to ~12 weeks for 3rd party ERPs and payment integration with the Process & workflow automation platform.

That was ultimately limiting their potential to serve the number of clients at a time.

So we decided to help them by building an integration hub like Zapier.

Now the question arises why do you need an API gateway in the first place?

Why do we need an API Gateway?

It is crucial to have an API gateway since it provides a unified point of entry for internal APIs. Using it, you can control user access. Moreover, it applies security policies, such as OAuth or JWT, and enables security measures, such as rate limiting. The API gateway is particularly important for securing microservices.

Leveraging AWS Platform and AWS Partner to Build an Integration Hub

AWS provides all the go-to solutions for building a cost-effective and reliable solution on the cloud. And building an integration hub is no different.

And being an AWS advanced consulting partner, AAIC showcases expertise with:

Amazon API Gateway Delivery
Amazon Cloudfront Delivery
AWS Lambda Delivery
AWS WAF Delivery
AWS Cloudformation Delivery

How Applied AI Consulting builds API-based Integration Gateway Powered By AWS Services

AAIC built the Integration Gateway with 4 main components: Flow, Filter, Transformer, and Adopter.

Using the component, inputs are taken from the client’s platform and transformed via an adapter that further talks to multiple ERP systems such as Microsoft Dynamics GP, Oracle Netsuite, etc.

Putting it more specifically,

Flow is created using one or more filters, transformers, and adopters. And each flow has a unique id.
The inputs are filtered through the Filter state, and based on the status condition (Like if something needs to be done or not) they are sent out to the transformer.
Then the transformer will look at the config mapping and transform the input JSON to the expected for as required by the adapter and corresponding action.
Finally, the adopter component will have the actions like creating invoices, creating vendors, creating employees, and more. Authentication can also be an action since it would be specific to the ERP in context.

Benefits of the API integration Gateway

It takes less than a week to go live for any of your customers.
It brings the ability to onboard 80% more customers with varied ERPs.
It’s a no-code low code reusable integration framework.
It abstracts the complexity and helps them integrate with existing ERP via a few clicks on UI.
Boosts the efficiency of businesses with ease and flexibility.
Automation of more than 30 tasks.

Well, we offer enterprises the best-in-class cloud deployment, CloudOps, Cloud Integration, Networking, and data engineering services over AWS. Hence, if you are facing any challenge in your scalability do reach out to us at vijayroy@appliedaiconsulting.com

7Targets Goes Serverless with Applied AI’s AWS Expertise

Fri, 08 Jul 2022 12:07:08 +0000

Executive Summary

AAIC, an AWS Advanced Consulting Partner, is using its AWS Service Delivery Program authorization to accelerate business growth and build its client confidence. The company’s strength is in its AWS skills and expertise through which it helped a leading sales tech platform in going serverless with zero deployment failure within 3 months.

About Client – 7Targets AI Sales Assistant

7Targets is a leading sales tech platform focused on sales force efficiency and productivity using its patented AI-based lead nurturing solution. It has a flagship product ‘AI Sales Assistant’ which can write emails and do follow-ups with the leads as well as read the received responses and act accordingly.

Expertise with Different Service Delivery Programs makes Applied AI Consulting an Effective AWS Partner

AAIC is an AWS advanced consulting partner with expertise in AWS lambda as well as other services. Being a Cloud System Integrator (CSI), it enables enterprises to create their application and big-data workloads safely to the AWS cloud with improved governance.

Applied AI Consulting has deep knowledge of Native AWS services and the best practices. AAIC has worked with scores of customers for service delivery.

Its 20+ AWS certifications and 7+ active cloud projects, make it a reliable partner for cloud-based projects that effectively showcase its expertise with:

Amazon API Gateway Delivery
Amazon CloudFront Delivery
AWS Lambda Delivery
AWS WAF Delivery
AWS CloudFormation Delivery

“We offer enterprises the best-in-class cloud deployment, CloudOps, cloud integration, networking, and data engineering services over AWS. And our growing customer base and positive feedback from them is a clear indicator of service excellence .”

Vijay Roy, CEO, Applied AI Consulting

AAIC Identifying 7Targets Challenges

7Targets provides an email-based AI Sales Assistant and a SaaS solution. The infrequent load of processing the received email via an event-driven architecture was one critical need. Apart from that, there was the requirement of externalizing the processing of sending and receiving emails. And that with a possibility of managing (start, stop, restart, etc) each of the leads and emails for supportability reasons.

Here are a few of the challenges from them

The cost of running was not in control and they needed pay-as-you-use mechanism without losing the security and elasticity aspect.
Their process lacked of an externalized way to manage the flow for sending and receiving emails.
Their existing monolith service was behind the load balancer with autoscaling, but the scale-up and scale down was not helping as the load was very infrequent throughout the day, multiple times.
They needed upgrades with zero downtime.

Ultimately, they were looking for an AWS Partner who is adept in native AWS services. Specifically, Amazon API Gateway, AWS Step Functions, AWS S3, AWS Cognito, AWS Lambda, Amazon CloudFront, AWS WAF, Amazon Comprehend, Amazon ECS Fargate, and Amazon Cloudwatch. And AAIC fulfilled all their requirements criteria.

AAIC Resolving 7Targets Challenges and Helping it Go Serverless with Zero Downtime

After understanding their challenges, the code structure, and the different microservices, the Applied AI team proposed the utilization of different AWS services to best suit their requirement.

Some of the major steps taken are:

Creating the step functions( state machine process lead, process lead response, etc) with various AWS lambda functions for each step. Where we used Python runtime and serverless.io framework. This gave the required control the customer needed for externalization of flow.
Sending the accepted received email in the S3 bucket using SES and processing them using lambda and step functions.
Processing the received response and categorizing based on an ML model running in lambda and certain properties available in the response like date, etc helped them keep the cost of the ML stack low.
To provide ease of development and deployment without any downtime we used Lambda functions and API Gateway.
Used Amazon CloudFront to Improve the access speed for downloading the content for their customers.
Helped them go serverless with Lambda, Step Functions, DynamoDB, AWS ECS Fargate, and RDS.
We used Python as the primary language which gave them confidence as the skill was not new to them.
Deploying and using the ML model from Lambda helped them get valuable inferences at a minimal cost.
Also, our usage of Comprehend gave them some quick wins.
Automated test to verify before deployments.
Additionally, we used AWS data migration services, ECR, and AWS cloud formation for utilizing related AWS and third-party resources.

Why AWS?

It’s a no-brainer that AWS is packed with all the go-to solutions for making a cost-effective and reliable solution on the cloud. Companies of all sizes understand it and use it to scale and resolve their various challenges. Some of the core reasons for 7Targets to choose AWS are mentioned below:

AWS services seemed more mature to the client to improve their current situation. Like AWS WAF, load balancers, step functions, secret managers, and more.
The client already knew about the AAIC and its advanced consultancy partnership with AWS.
The team (both 7Targets and AAIC) had experience and expertise on AWS.

Why the Customer Chose AAIC as their AWS Partner

The following factors influenced their decision to choose AAIC:

AAIC’s serverless-api-generator tool that generates production-ready REST API code along with UTs and the pipelines. The AAIC team had many services on serverless beyond the ECS. And the client knew this generator would be useful for getting pipelines quickly.
Usage of aws_lambda_powertools ensured the customer that AAIC brings the required standards too.
The AAIC AWS-certified and experienced team of cloud engineers.
AAIC’s similar previous work helped them take this decision.
Also, AAIC’s DevOps accelerator [DevOps-in-a-box] that potentially reduces the DevOps pipeline implementation by 60% got their attention.

Future Plans

The AWS partner and the client continue to work together. Keeping a tab on production and MLOps is key for the client, which AAIC helps with. Cost optimization is a continuous process and AAIC does great there. Also, new feature development and maintenance of existing is a critical responsibility.

As the 7Targets production DB and usage increases, they need to continue to improve on using properly sized resources, upgrade databases, etc, and AAIC helps there.

AWS Services Used as Part of the Solution

AWS S3, AWS ECR, AWS Lambda, AWS ECS Fargate, Amazon CloudWatch, AWS Secrets Manager, Amazon SNS, Dynamo DB, AWS step functions, AWS WAF, Cognito, RDS.

Benefits

Usage of serverless for inference using the ML model has helped the customer from a cost perspective.
Usage of Lambda and Step function that scaled easily to their increasing load with increasing customers.
The monitoring dashboard using AWS Cloudwatch gives a very clear picture of the workload and health

7Targets Solution Architecture

Are Your Microservices Not Well-Managed?

Wed, 01 Jun 2022 07:20:09 +0000

In the past few years, many companies have shifted from a monolithic to a microservices approach. However, as with any approach to application development, the microservices architecture has its own challenges.

There are several use cases where organizations noticed an increased complexity and effort to develop applications with a microservice framework.

This is what happened to one of our clients too!

Being a leading SaaS-based company in Sales and marketing, they wanted to do upgrades at will along with predictability.

And because their existing microservices were not well-managed in terms of deploying only the updated ones. They faced subsequent other problems too.

Want to scale your business? Let’s connect!

Challenges you Face When Your Microservices are not Well-Managed

A small change of code would result in the deployment of almost all the services.
Any modification had a significant impact, and even though the process is automated, testing may take a long time.
Instead of click-button automation, upgrading is an activity itself that requires the entire team to collaborate.

How To Manage Poorly-Managed Microservices

The first step to solving any problem is to understand the situation well. The causes and the effects. This is why our automation experts first engaged with your team to understand the challenges & requirements.

Then, after understanding the challenges, the code structure, and the different microservices we take these key steps:

Restructuring the code to differentiate the services into separate folders and the common dependent code into one.
Creating pipelines for each of the services with the proper code component dependencies defined in the pipelines.
Separating the GitLab repository for each service to provide ease of maintenance for their small engineering team.
Assisting you in developing new export microservices as per the requirement.
Ensuring the proper usage of serverless and EKS with the right configuration for some services running in JRE in a docker container ensures zero downtime upgrade.
Providing the proper README and other details makes it easy for the customer to maintain all the services well in this structure.

To help our readers better understand the solution, here is the graphical presentation of our DevOps pipeline for serverless microservices and zero downtime upgrades.

Need DevOps Engineers? Hire experts

DevOps Pipeline For Serverless Microservices and zero Downtime Upgrade

Technology Stack For Serverless Microservices & Zero Downtime Upgrade

Serverless.io

Step functions

EKS

Dynamo

SNS

SQS

Lambda Functions

GitLab CI/CD

RDS

As you might have realize that adopting a certain technology is not enough. You need to understand your requirement, environment and the right technique to implement the solution. This is where AAIC team bring their expertise and help you get the scalable solution.

As in above example, we not only resolved their poorly managed microservices but also assisted them in achieving zero downtime upgrades.

Want to know more? Book a free 30 minutes consultation call

Build Serverless Backend Solutions with AWS to Reduce your Infrastructure Cost

Tue, 31 May 2022 07:46:04 +0000

One of our customers called ClickToConsult which provides an E platform for service seekers to access quality professionals & consultancy via audio & video conferencing, wanted to give instant access to the services by saving time and costs. It offers a mobile application, which is available in the App Store and Play Store.

Want to build a mobile app? Let’s talk.

As the client wanted to scale, we helped them to build a web-based interface to manage administration activities.

We hosted the backend in AWS serverless lambda. Lambda functions work on-demand when there is a request to the API gateway. And when there is no request to serve, lambda functions will shut down automatically – which saves the cost

Lambda functions can also scale on demand. So in future when there is a load on the system, it can easily scale-up up to a certain threshold.

Wondering about AWS? Talk to our expert.

With this, the consultants can create their profile and users can view the consultant profile using the platform to book an appointment. We also integrated the app with the third party Razorpay to handle all the transactional requests.

The service providers can use Razorpay as the payment gateway to handle the transactions. Firebase is used to send push notifications to android and iOS platforms.

If you have any questions, book a free consultation with us.

We used to following technologies to deliver the solutions:

AWS Step Functions
AWS Lambda
AWS RDS
AWS S3
AWS SES
AWS ECR
AWS Cloudfront
AWS SNS
AWS SQS
AWS API Gateway
AWS Cloudwatch
AWS ELB
AWS Cognito
AWS WAF
AWS CloudFormation
AWS Route53

With our solutions, ClickToConsult is offering consultancy across India and the middle east

from their home or office. The serverless solution helped the client to save the cost as developers are only charged for the server space they used and no cost involved in managing the infrastructure.

Read the related case study here.

What is Filebeat and why is it imperative?

Mon, 18 Apr 2022 11:20:32 +0000

The beats are open-source and lightweight data shippers. You can install these as agents on your servers to dispatch operational data to Elasticsearch. You can send data directly via beats to Elasticsearch or via Logstash. Here (in Logstash) you can further process and develop the data.

Filebeat creates a low memory footprint to forward and centralize logs and files and you don’t need to use SSH especially when you have numerous servers, virtual machines, and containers that create logs.

Filebeat is a logging agent. You can install it on the machines that create the log files. Filebeat forwards the data to Logstash or directly into Elasticsearch for indexing.

Filebeat Processors

If you are not using Logstash but still want to process/customize the logs before sending them to ElasticSearch, you can use the Filebeat Processors. You can decode the JSON strings, add various metadata (e.g. Docker, Kubernetes), drop specific fields, and more.

If you want to send logs from Filebeat directly to ElasticSearch this provides benefits such as

We were using logstash for parsing the logs to elasticsearch. But, due to heavy traffic, logs were getting lost and delayed on the elasticsearch. We have modified the workflow and parsed the logs from filebeat to elasticsearch. Now, We are getting the logs in real-time and there is no delay in the logs coming to elasticsearch.

The below Image shows the heavy traffic(6 Million Hits in 15 Minutes) coming from pods and the filebeat is shipping the data in minimal time.

So, The filebeat can handle heavy traffic.

It can support encryption
Decreases the latency involved with the log processing by a middle component like Logstash.

Logstash performance works on a few factors, e.g.

The number & complexity of filters you used
The number of filters, output workers & available system resources.

How do you tune your internal pipeline changes over recent versions? Hence offering your config and versions of Logstash helps you with how you tune it in the best possible way. Besides that, Logstash processing will be limited by the throughput of the slowest output.

3. Cost Reduction

If you ship the logs from filebeat to elasticsearch, you will save the cost of resources consumed by the Logstash pods.

4. Logs will get reflected in ElasticSearch in real-time.

The below Image shows the pod logs timestamp

As shown in the below screenshot, At the same time a log was found on Kibana.

5. There is no loss of logs.

When we were passing the logs through the logstash to Elasticsearch. Logs count on the microservices pod and logs in the Kibana were not matching. We noticed only 20% of the microservices pod logs were there on Kibana. After modifying the workflow, Logs count was matching.

Processors

You can define processors in the Filebeat configuration file per input. To define a processor:

you define the processor name
an optional condition
a set of parameters

Where:

specifies a processor that accomplishes some kind of action, for example choosing the fields that are already exported or adding metadata to the event.
specifies an optional condition. If the condition is present, then the action is executed only if the condition is met. If no condition is set, then the action is always executed.
is the list of parameters to pass to the processor.

Let’s take an example where we have 2 APIs (vehicle and furniture APIs) and each API has multiple microservices.

These microservices are deployed in the Kubernetes cluster as Deployment.

We use Filebeat Autodiscover to fetch logs of pods.

Decode logs are structured as JSON messages using JSON Options.

Add Kubernetes metadata into the log so that we can add fields based on the Pod label.

Pod labels will be present under Kubernetes. labels field, e.g. app label is present under Kubernetes.labels.app.

Use the add_fields processor to add fields such as api_name and microservice_name.
Use the conditional to specify when to add these fields.
To add fields at the top level, set the target to an empty string.
Use the drop_fields processor to remove unwanted fields.

Filebeat output

Finally, send logs to ElasticSearch using the Output.

Let’s connect!

Cloud Champion

Manan Tank is a passionate cloud expert. He is a fast learner and contributes to our major projects. In his free time, he loves to travel and do road trips.

Cloud Champion

Nilesh is a cloud expert. His hardwork is helping us to be at the forefront of CX. In his free time, he loves to sketch and play video games.

Why We need Process Mining?

Fri, 08 Apr 2022 11:52:57 +0000

With the changing economic environment, today’s businesses are embracing process-based approaches to achieve their business goals. Organizations depend on BPM tools and business process modeling to bring operational excellence. In this blog, I am discussing what process mining is and why it is important for applications.

What is Process Mining?

Process mining is a family of techniques relating to the fields of data science and process management to support the analysis of operational processes based on event logs.

What is a process?

Let’s get back to basics by defining processes first.

A process is a series of actions or steps repeated in a progression from a defined or recognized ‘start’ to a defined or recognized ‘finish’.

The purpose of a process is to establish and maintain a commonly understood flow that allows a task to be completed as efficiently and consistently as possible.

Want to define your processes?

Every business process step leaves a digital footprint in your transactional systems in the form of event log data. It is using this data that process mining software works to create a living picture of what your actual processes really look like, which does not always match the definition of that particular process.

Of course, some process steps don’t necessarily take place in a transactional system either sending an email or opening a spreadsheet, for example.

Task mining is the technology that collects that user’s desktop data. Combined with process mining, it gives the most complete view of how work gets done within an organization

What is Process Mining?

Process mining is defined as an analytical discipline for discovering, monitoring and improving processes as they actually are and not as you think they might be.

Process Mining works by extracting knowledge from event logs readily available in today’s information systems, in order to visualize business processes and their every variation as they run.

Need help in process mining?

Why Process Mining Is Important For Any Application?

To explain the answer to this question, I want to talk about one of my past experiences. I was working on one ecom application for one of my clients. We were using a logger table to track the activities of users on our website.

Suddenly, one night during rush hours customers started facing errors like the website was unavailable. I’ve refreshed the table, deleted some of the old records, added indexes and where clauses, and fixed that performance issue. In between, the client lost some of his orders and that was his loss.

Then we researched process mining techniques that will track the errors and exceptions from event logs and provide automated resolutions depending upon the tracked error or exception. due to a huge number of records on a particular table.

I’ve refreshed the table, deleted some of the old records, added indexes and where clauses and fixed that performance issue. In between, the client lost some of his orders and that was his loss.

After that, we scheduled one meeting and tried to track down the exact solution for this kind of issue and it will never happen in the future in any case.

There will be an automated process to resolve that issue at an instance.

Then we have researched process mining techniques that will not only track the errors and exceptions from event logs, but also provide automated resolutions depending upon the tracked error or exception.

What are common business processes?

Common business processes include Purchase-to-Pay (P2P), Order-to-Cash (O2C), or Customer Service processes, for instance.

And while nearly every company has some version of these processes as the backbone of their business, there are many others that support a company’s daily operations, including:

Accounts Payable processes
Accounts Receivable processes
Procurement Processes
Order Management processes
Inventory Management processes

These are just a sample, of course. Moreover, different companies define certain processes differently depending on their business needs, the systems they use, and other variables.

By their nature, processes are not static — nor do they always follow the path defined for them. Even the best-made plans go awry, and over time these deviations can become the rule without continual business process management and process improvement.

Dynamic markets also force change: customer expectations, new product lines, acquisitions, changing geographies, and any number of other things can impact a process’ ability to perform at full capacity.

This is where process mining comes in, as it enables process owners to find and fix inefficiencies in their business processes by giving them complete real-time visibility.

How to Implement Process Mining techniques?

The input for process mining is always event logs or logs which we have in our application. There are a lot of third-party tools as well as services available by which we can implement process mining.

The tool we used at that time was Celonis. There are demos available on the official Celonis website on how we implement the same in our application.

There is a free membership available as well to check if this is definitely helpful for your business or not. We used our event log table as the input for Celonis.

We can use excel/csv or any integration tools output like oracle, sap, or Salesforce. Celonis analyzes data and provides behavior depending upon the files you have uploaded. Sample file attached.For the trial, we can start with a sample file.

This is the sample process mining. After analysis we can track and add action for any specific error and then that will be output to our application. Here we can monitor, track and analyze the performance of the system.

What is the need of Process Mining?

With process mining, organizations can expose what’s really happening in their processes instead of operating under assumptions. They can then identify the root causes of bottlenecks in real-time, optimize their resources and scale with full productivity and confidence.

Let’s connect!

Ashwini Joshi

Team Lead

Ashwini Joshi is a cloud expert. She is handling major projects with us and a passionate Bharatanatyam dancer. In her free time, she loves to paint too.

How to deploy Lambda Container Image using Serverless Framework

Tue, 05 Oct 2021 13:06:08 +0000

What we are going to do?

Create a simple python based AWS Lambda Container and deploy it on AWS using Serverless Framework.

Let’s get started…!

There are 3 steps involved in deploying AWS container:

Writing Lambda Code or the Lambda function in Python
Creating a Dockerfile
Creating serverless.yml file and deploying the function

Writing Lambda Code

For the tutorial purpose, let’s write a simple python file and name it as app.py

def handler(event, context):
 print("Hello From Inside the Lambda Function")
 return event

Creating Dockerfile

Lets create a Dockerfile in the same directory.

# Pull base lambda python3.8 docker image
FROM public.ecr.aws/lambda/python:3.8

# Copy python requirements file
COPY requirements.txt .

# Install the python packages
RUN pip install -r requirements.txt

# Copy function code
COPY app.py ${LAMBDA_TASK_ROOT}

# Set the CMD to your handler (could also be done as a parameter override outside of the Dockerfile)
CMD [ "app.handler" ]

Explanation

Use Python based Lambda Docker Image from Docker Hub as base image
Copy requirements.txt if there are some external packages that needs to be installed. (Optional)
Install the requirements using pip. (Optional)
Copy Lamdba code we wrote above in the lambda directory.
Set the command to run the function.

Create Serverless file

We will create a serverless.yml file in the same directory which will have some lambda configurations.

service: test-app
frameworkVersion: '2'

provider:
 name: aws
 stage: dev
 region: us-east-1
 ecr:
 images:
 latest:
 path: ./

functions:
 print-hello:
 image:
 name: latest

Final directory Structure

Deploying the code

In the terminal, go to the above code directory and enter below command.

sls deploy

This will first create the docker image and push that image on AWS ECR. Then it will deploy the lambda function specifying it to use the above created docker image.

How did we use the model?

We had to run real time inference of the data on AWS Lambda and for that we used pytorch library which is around 700MB in size. So we had to come up with this approach of deploying the Lambda Container.

Summing up!

In this article, I have demonstrated the simplest workflow required to deploy python based Lambda Container on AWS. You can also use your own base image to run AWS Lambda Container. You can find that tutorial here.

Hit me up at gaurav@appliedaiconsulting.com if you have any questions.

Thanks for reading!

Product Engineering & Development | Applied AI Consulting

Understanding AWS IAM

IAM Features

Shared access

Fine-grained access

Authenticating IAM Users & Groups

Users and User Groups

IAM Policies

IAM Roles

Takeaway

Related posts

Choosing between SQL and NoSQL; Amazon Aurora and DynamoDB

Structure

Types of NoSQL databases

Schema vs Schema-less Pros and Cons

Transaction Processing

Amazon Databases

Vertical Scaling vs Horizontal Scaling

Amazon Aurora

Amazon DynamoDB

Related posts

Kubernetes Security 101: Understanding RBAC and Service Accounts

Role & ClusterRole

Role Based Access Control (RBAC)

Related posts

Exploring Container Orchestration Options with AWS ECS, EKS, and Fargate

AWS ECS

AWS Fargate

Amazon EKS

Conclusion

Related posts

Serverless or Containers, Which is the Better Option?

Serverless Computing

Management hassle

Pay for what you use

Highly available

Memory

Traffic

Containers

Container management

Compute power

Memory

Use Cases

Traffic

Cost Difference

Scenario 1

Scenario 2

Conclusion

Related posts

Are Serverless and Microservices Made for Each Other?

Serverless microservices: how it works

Typical Serverless Microservice-based Architecture

Benefits of serverless microservices

Use Cases

Challenges

In a nutshell

Related posts

The Problem with Microservices

Microservices benefits

Microservices are build for autonomy, specialization, and scalability

Challenges to Using Microservices Architectures

1. Deployment Design

2. Security

3. Testing

4. Operational complexity

Complexity in Application Performance Monitoring

5. Communication

Complexity and improper configuration increases latency in microservices

When to Avoid Using Microservices

Undecided domain

Inability to embrace a DevOps culture

Small application size

Should You Adopt Microservices?

Related posts

Monolithic vs Microservices – Principles and Practices

Monolithic applications

Disadvantages of Monolithic applications

Service Oriented Architecture

Principles of microservices

Microservices advantages