DEV Community: Ritam Debnath

Things Nobody Told You About Cloud-Native Architecture

Ritam Debnath — Fri, 11 Nov 2022 02:25:20 +0000

For deployments in all areas of IT, cloud-native architecture has become a new sensation. Most of the developers are exclusively using cloud deployment nowadays. Even though cloud-native architecture has become so popular, not all its benefits are known.

An IT or software solution built on cloud-native architecture works with modern settings. When you create an app project, you must take good care of the production environment. And cloud Native Architecture ensures that your project can live in the cloud.

Through this guide, I will discuss every key takeaway you need to know about Cloud Native Architecture.

What is Cloud-Native Architecture?
Cloud-Native applications are those that are explicitly designed for a cloud-based computing architecture. Cloud-native applications use microservice-based architecture since microservices are the heart of Cloud Native Architecture. The purpose of the microservices is simple! They make the application flexible and adaptable to a cloud architecture.

Cloud-Native Architecture takes many advantages. But the cloud takes the most benefit from the things it does without error. While reducing risks and improving quality, it will provide horizontal scalability, fault tolerance, and flexibility.

Because of containers, you can change this type of application easily. All you need to do is to update its microservices. Developers can move the cloud with ease, scale-out rapidly at any time.

A Brief History of Cloud-Native Architecture
Cloud-Native can mean a lot of things. The idea of connecting multiple computers and making a powerful application for that has always been part of the discussion.

By the early 1970s, E-mail had become the most successful large-scale distributed application of ARPANET. In the meantime, distributed computing was becoming the highlighted discussion-much more or less invented cloud computing by that time.

Also, back in 2012, developers had designed cloud-native Fusion 5G Core. The cloud-native network functions CNFs and CSPs held the maximum benefit of microservices, containers, and automation.

Well-known internet giant Netflix leveraged cloud technologies. To date, it remains one of the most discussed projects. Additionally, you can consider features and cloud-based microservices transformation as an example.

Why Cloud-Native Platform Needed?
Cloud-Native Architecture is meant to operate in a cloud environment. The apps are packaged in containers. However, both the developers and organizations need Cloud-Native applications. To build a platform, we need Cloud Native to test, deploy and manage services.

Here are a few reasons why Cloud Native Platform is essential:

Microservices are part of the Cloud Native Architecture. An application is divided into services by microservices. Each service has its data and provides specific business goals. It only works for those problems which are scaled horizontally. Microservices have end-to-end features for developing, testing, and operating components.

Cloud-Native apps depend on containers. By using this software, microservices run independently and are kept from interacting with one another. Container technology makes cloud-native portable across different infrastructures and environments. This lets applications scale horizontally.

In Cloud Native, DevOps is a vital component. Cloud-native approaches to application development follow agile and DevOps principles. Communication and collaboration are encouraged in DevOps. Processes are managed and changed rapidly and easily.

How Cloud-Native Architecture Makes Your Business Better?
Cloud-Native applications are made for taking advantage of the speed and efficiency of the cloud. The top benefits business will get by adopting Cloud Native Architecture. Such as:

Features

Cloud-native technology is based on pay-per-use models. That means you have to pay for what you use. Because cloud boosts the productivity of IT personnel, the operation cost gets lower. Also, hosting costs are meager.

2. Scalability:

Because of scalability, data can scale up at any time. There is no limitation on the amount of data that can be processed. Any kind of change won’t harm others. Components of applications can update faster in Cloud Native Architecture. Businesses can take these advantages to fulfill the demand.

3. Resilient and Manageable

Resilient and easily manageable are other features of Cloud Native application. If somehow one microservice failed. There will be no effect on adjacent services because cloud-based applications use the container.

Using manageability can update individual application components without turning the lights off all over.

4. Observable:

With observability, all information is available immediately. The observability of multiple components running together helps detect any errors. The feature can detect even the smallest of mistakes. Likewise, it identifies whether the system has been configured correctly by observing API calls.

5. Easy to Control:

Cloud-Native application is popular in part because of its ease of use. Using automation, cloud-native deploys apps and updates, so all others won’t be affected if one microservice is updated. Developers can track updates.

6. Monitoring:

Monitoring is a tool provided by Cloud-Native Architecture. It helps you with monitoring the system’s health. It can observe system usage, user behaviors and give insights value. It also shows your business outcomes.

Is it Necessary to Use Containers for Cloud-Native Architecture?
Container work with a virtual environment. Below, I’m discussing whether containers are essential in Cloud Native is given.

Indeed, Container plays a massive role in the current evolution of platform building. But in many ways, the container doesn’t complete its work properly. Developers primarily focus on business needs which they want to finish in a more resilient and flexible way. However, this is not something that containers provide. Containers being this poorly serverless ecosystem.

On the other hand, Containers are beneficial for Cloud-Native Applications. Its reliance and immutable release artifacts are implementation details. The container can automatically schedule and launch whenever you want to. Also, many Cloud-native require this feature.

Conclusion

This article explains everything you need to know about Cloud Native Architecture. The impact of cloud technology on business is very noticeable. This technology has changed the view of developing any applications. The business industry is rapidly moving towards the Cloud.

Cloud-Native releases more features every now and then to help users manage data, build apps, and manage them quickly. As a result of its affordable price, developers don’t think twice about buying it.

Addressing the Current Challenges of Patching Container Vulnerabilities

Ritam Debnath — Fri, 11 Nov 2022 02:16:50 +0000

While working on a process of improving the container secure supply chain, I often need to go over the current challenges of patching container vulnerabilities. With the introduction of Automatic VM Patching, having those conversations are even more challenging because there is always the question: “Why can’t we patch containers the same way we patch VMs?” Really, why can’t we? First, let’s look at how VM and container workloads differ.

How do VM and Container Workloads Differ?
VM-based applications are considered legacy applications, and VMs fall under the category of Infrastructure-as-a-Service (IaaS) compute services. One of the main characteristics of IaaS compute services is the persistent local storage that can be used to save data on the VM. Typically the way you use the VMs for your application is as follows:

You choose a VM image from the cloud vendor’s catalog. The VM image specifies the OS and its version you want to run on the VM.
You create the VM from that image and specify the size of the VM. The size includes the vCPUs, memory, and persistent storage to be used by the VM.
You install the additional software you need for your application on the VM.

From this point onward, the VM workload state is saved to the persistent storage attached to the VM. Any changes to the OS (like patches) are also committed to the persistent storage, and next time the VM workload needs to be spun up, those are loaded from there. Here are the things to remember for VM-based workloads:

VM image is used only once when the VM workload is created.
Changes to the VM workload are saved to the persistent storage; the next time the VM is started, those changes are automatically loaded.
If a VM workload is moved to a different hardware, the changes will still be loaded from the persistent storage.

How do containers differ, though?

Whenever a new container workload is started, the container image is used to create the container (similar to the VM). If the container workload is stopped and started on the same VM or hardware, any changes to the container will also be automatically loaded. However, because orchestrators do not know whether the new workload will end up on the same VM (or hardware due to resource constraints), they do not stop but destroy the containers, and if a new one needs to be spun up, they use the container image again to create it.

That is a major distinction between VMs and containers. While the VM image is used only once when the VM workload is created, the container images are used repeatedly to re-create the container workload when moving from one place to another and increasing capacity. Thus, when a VM is patched, the patches will be saved to the VM’s persistent storage, while the container patches need to be available in the container image for the workloads to be always patched.

The bottom line is, unlike VMs, when you think of how to patch containers, you should target improvements in updating the container images.

A Timeline of a Container Image Patch
For this example, we will assume that we have an internal machine learning team that builds their application image using python:3.10-bullseye as a base image. We will concentrate on the timelines for fixing the OpenSSL vulnerabilities CVE-2022-0778 and CVE-2022-1292. The internal application team's dependency is OpenSSL <- Debian <- Python. Those are all Open Source Software (OSS) projects driven by their respective communities. Here is the timeline of fixes for those vulnerabilities by the OSS community.

2022–03–08: python:3.10.2-bullseye Released
Python publishes puthon:3.10.2-bullseye container image. This is the last Python image before the CVE-2022–0778 OpenSSL vulnerability was fixed.
2022–03–15: OpenSSL CVE-2022–0778 Fixed
OpenSSL publishes fix for CVE-2022–0778 impacting versions 1.0.2–1.0.2zc, 1.1.1–1.1.1m, and 3.0.0–3.0.1.
2022–03–16: debian:bullseye-20220316 Released
Debian publishes debian:bullseye-20220316 container image that includes a fix for CVE-2022–0778.
2022–03–18: python:3.10.3-bullseye Released
Python publishes python:3.10.3-bullseye container image that includes a fix for CVE-2022–0778.
2022–05–03: OpenSSL CVE-2022–1292 Fixed
OpenSSL publishes fix for CVE-2022–1292 impacting versions 1.0.2–1.0.2zd, 1.1.1–1.1.1n, and 3.0.0–3.0.2.
2022–05–09: debian:bullseye-20220509 Released
Debian publishes debian:bullseye-20220316 container image that DOES NOT include a fix for CVE-2022–1292.
2022–05–27: debian:bullseye-20220527 Released
Debian publishes debian:bullseye-20220527 container image that includes a fix for CVE-2022–1292.
2022–06–02: python:3.10.4-bullseye Released
Python publishes python:3.10.4-bullseye container image that includes a fix for CVE-2022–1292.

There are a few important things to notice in this timeline:

CVE-2022–0778 was fixed in the whole chain within three days only.
In comparison, CVE-2022–1292 took 30 days to fix in the whole chain.
Also, in the case of CVE-2022–1292, Debian released a container image after the fix from OpenSSL was available, but that image DID NOT contain the fix.

The bottom line is:

Timelines for fixes by the OSS communities are unpredictable.
The latest releases of container images do not necessarily contain the latest software patches.

SLAs and the Typical Process for Fixing Container Vulnerabilities
The typical process teams use to fix vulnerabilities in container images is waiting for the fixes to appear in the upstream images. In our example, the machine learning team must wait for the fixes to appear in the python:3.10-bullseye image first, then rebuild their application image, test the new image, and re-deploy to their production workloads if tests pass. Let's call this process wait-rebuild-test-redeploy (or WRTR if you like acronyms:)).

The majority of enterprises have established SLAs for fixing vulnerabilities. For those that have not established such yet, things will soon change due to the Monitoring Strategy Guide. According to the FedRAMP rules, high severity vulnerabilities must be remediated within 30 days. Executive Order for Improving the Nation’s Cybersecurity. Many enterprises model their patching processes based on the FedRAMP 30/90/180 rules specified in the FedRAMP Continuous CISA’s Operational Directive for Reducing the Risk of Known Exploited Vulnerabilities has much more stringent timelines of two weeks for vulnerabilities published in CISA’s Known Exploited Vulnerabilities Catalog.

Let’s see how the timelines for patching the abovementioned OpenSSL vulnerabilities fit into those SLAs for the machine learning team using the typical process for patching containers.

CVE-2022–0778 was published on March 15th, 2022. It is a high severity vulnerability, and according to the FedRAMP guidelines, the machine learning team has till April 14th, 2022, to fix the vulnerability in their application image. Considering that the python:3.10.3-bullseye image was published on March 18th, 2022, the machine learning team has 27 days to rebuild, test, and redeploy the image. This sounds like a reasonable time for those activities. Luckily, CVE-2022-0778 is not in the CISA's catalog, but the team would still have 11 days for those activities if it was.

The picture with CVE-2022–1292 does not look so good, though. The vulnerability was published on May 3rd, 2022. It is a critical severity vulnerability, and according to the FedRAMP guidelines, the machine learning team has till June 2nd, 2022, to fix the vulnerability. Unfortunately, though, python:3.10.4-bullseye image was published on June 2nd, 2022. This means that the team needs to do the re-build, testing, and re-deployment on the same day the community published the image. Either the team needs to be very efficient with their processes or work around the clock that day to complete all the activities (after hoping the community will publish a fix for the python image before the SLA deadline). That is a very unrealistic expectation and also impacts the team's morale. If by any chance, the vulnerability appeared on the CISA's catalog (which luckily it did not), the team would not be able to fix it within the two-week SLA.

That proves that the wait-rebuild-test-redeploy (WRTR) process is ineffective in meeting the SLAs for fixing vulnerabilities in container images. But, what can you currently do to improve this and take control of the timelines?

Using Multi-Stage Builds to Fix Container Vulnerabilities
Until the container technology evolves and a more declarative way for patching container images is available, teams can use multi-stage builds to build their application images and fix the base image vulnerabilities. This is easily done in the CI/CD pipeline. This approach will also allow teams to control the timelines for vulnerability fixes and meet their SLAs. Here is an example how you can solve the issue with patching the above example:

FROM python:3.10.2-bullseye as baseimage 
RUN apt-get update; \ 
    apt-get upgrade -y 
RUN adduser appuser 

FROM baseimage 
USER appuser 
WORKDIR /app 
CMD [ "python", "--version" ]

In the above Dockerfile, the first stage of the build updates the base image with the latest patches. The second stage builds the application and runs it with the appropriate user permissions. Using this approach you awoid the wait part in the WRTD process above and you can always meet your SLAs with simple re-build of the image.

Of course, this approach also has drawbacks. One of its biggest issues is the level of control teams have over what patches are applied. Another one is that some teams do not want to include layers in their images that do not belong to the application (i.e. modify the base image layers). Those all are topics for another post 🙂

Making Your First Contribution to Open Source

Ritam Debnath — Thu, 14 Jul 2022 04:15:52 +0000

Open source software powers a huge portion of the Internet and many applications that we use every day. Massive projects like Linux, WordPress, and Firefox are all open source, as well as popular projects like React Native, Angular, and Kubernetes.

Even if the application that you’re using isn’t open source, chances are that some of its downstream dependencies are. For proof of how interconnected open source packages have become in today’s web development, look no further than the story of how the removal of one 11-line open source package took out web development projects around the world:

So we know that open source software is ubiquitous, but where does all of that open source software actually come from? Open source projects arise from the efforts of thousands of maintainers and contributors, many of them volunteers. Anyone can download and use the source code of an open source project — and anyone can add their contributions to that project too. At BigCommerce, we have a number of open source projects that we maintain, including Cornerstone, Stencil CLI, and BigCommerce for WordPress. Those projects are maintained by our engineering teams, but they’re also open to contributions from external developers.

If you’re curious about open source, but you’re not sure where to begin, this post is for you. We’ll talk about what open source means and run through a few of the reasons you might want to consider becoming a contributor. Then, we’ll outline the steps you can take to make your first contribution. Along the way, we’ll gain insight from our friends at Brand Labs, BigCommerce partners who are active in open source, with core contributions to Cornerstone and Stencil CLI.

What Is Open Source?
Open source software has a few key characteristics:

It’s free to use
The source code is accessible
Developers are free to modify the source code for their own purposes, including for commercial use

Some open source projects are completely not-for-profit and run by volunteers. Others are offshoots of proprietary software products, like the open source repositories maintained by BigCommerce. Most, but not all, open source projects accept contributions from the public.

The concept of open source was built upon ideas around free software dating back to the early days of software development, but coalesced into a movement with the founding of the Open Source Initiative in 1998. Today, there are thousands of open source projects run by maintainers from around the world.

There are a number of approved licenses that open source software projects can use. Many BigCommerce projects are licensed under the MIT License, which grants users the ability to use, modify, and distribute the software free of charge.

Advantages of Open Source Software

The first advantage we’ll discuss won’t be surprising — open source software is free, which is a definite plus. But, that low cost to entry can also be a powerful driver of technological innovation. A prime example is Linux, which powers a large portion of web servers. According to W3Techs, Unix web servers power about two thirds of sites on the internet, and many if not most of those are running Linux. Why is Linux so dominant? It’s simple — a Windows server license costs money while Linux is free. Robert DeBoer, Software Engineer at Brand Labs, sums it up: “Linux is this thing that you can’t live without and somehow it’s free. And it’s great — I can keep installing server after server after server.” That ability to scale up infrastructure at a low cost was a key contributing factor to the spread of the internet.

Another huge advantage for developers is that it saves time and effort. Open source software fits directly into the patterns that many modern software developers use to build out projects. Instead of building something completely from scratch, it makes sense to look for a framework or an existing project that provides a foundation, a starting point, that you can modify to fit your specific needs. That allows you to build upon existing software in a modular way instead of having to reinvent the wheel with every new project. “Open source software gives you an opportunity to grab something and own it without having to spend all the time writing it, and there’s a certain benefit to that,” Robert says.

Why Should I Contribute to Open Source?

You don’t have to contribute to open source software to benefit, but there are lots of reasons why you might want to dive in and get involved. Whether you’re interested in stretching your skills as a programmer, want to improve the software that you already use, or would like to connect with a network of like-minded individuals, contributing to an open source project can get you there.

1. Further your career.

In addition to your portfolio, open source contributions are a publicly visible, tangible indication of your skills — and that’s something prospective employers look for. Even if you’re not on the market for a new position, making contributions to open source projects is a great way to exercise skills outside of your day job and stretch yourself by solving new problems. Beyond that, open source contributions are a signal that you’re passionate about the technology you work with, and that’s a valuable quality to future employers and teammates.

2. Understand the inner workings of a project.

Diving into the source code is an essential way to understand a new technology on a deeper level. Carson Reinke, Development Manager at Brand Labs, explains how this concept influenced his entry into open source projects. “It’s really when I got into more Ruby and Rails development that I started embracing the open source aspect. When there’s a failure in the documentation, you just go look at the code. And it really kind of clicked with me. I’m like, ‘Well, I’ll just go look at how it works and really understand it that way’.”

3. Make a project you use better.

Many open source contributors make their first contribution because they see an opportunity to make a project that they already use better. Maybe they fixed a bug or added a useful new feature — in that case, submitting a pull request so the broader community can also benefit just makes sense.

This kind of crowd-sourced development is one reason why many open source projects are so robust. If many developers and organizations have projects that depend on an open source product, they have an incentive to make sure that the quality of that dependency is high. Not to mention, the more developers who are scoping out bugs and adding new features, the more can be accomplished and the better that project will be.

4. Connect with a community.

Getting involved with an open source project can be a great way to make connections with fellow collaborators. Many open source projects have thriving communities around them. For example, WordPress boasts over 1500 meetup groups around the world, with 700,277 members. While only a portion of those members are actively contributing code to WordPress, the WordPress community emphasizes the fact that everyone has something to contribute, and you don’t have to contribute code to make an impact. You can help with documentation, translations, and support tickets in addition to patching bugs.

5. Give back.

For some developers, contributing to an open source project is a way of paying credit to a software product that’s being used for free. “If you use a project, you really need to contribute to it,” Carson says. “That’s the debt that you owe to this project. That’s the licensing fee.”

It’s easy to begin taking open source projects for granted, but it’s important to keep in mind that many open source projects are managed by volunteers and sustained by donations. Providing your time and skills to keep a project going is the best way to make sure it’ll be there to use in the future.

Making Your First Contribution

Now that we’ve reviewed a few of the reasons to contribute to open source…how do you get started? If you’ve never contributed to a crowd-sourced project before or you’re new to GitHub, making your first contribution can be intimidating. Not to mention, it can be difficult to know where to begin. How do you find your niche to begin making a difference?

Something to keep in mind is that you don’t have to take on a huge task to have an impact. “What really pushes these projects along at the end of the day is not the one or two giant contributions. It’s the hundred small contributions that happen every day that really prop it up,” Robert says. We couldn’t agree more, and in the next section, we’ll discuss how you can choose the right project and task, and we’ll go through the process of submitting a contribution step-by-step.

1. Pick a project.

For many people getting started with open source development, the most obvious place to start is with a project that you already use day to day, but that doesn’t have to be the case. Other good reasons for choosing a starter project might be that the project has an active and supportive community around it, or it’s a technology that you want to learn more about.

If you’re new to open source and a newbie developer, choosing a project that has a lot of resources around it is a good idea. Whether that’s great documentation or a forum full of active users, you won’t be alone as you work through a problem.

If you want to browse projects that are actively looking for contributions (including by first-timers), up-for-grabs.net is a site that lists repositories requesting help from outside developers. Codetriage.com is another great resource to discover new projects. It’s a collection of open source repositories that you can filter by language. You can also sign up to have a new open issue emailed to your inbox every day so you can be sure that you don’t miss your opportunity to get involved.

2. Find a good first issue.

So you’ve found a project that speaks to you. But what’s the best way to identify which issues need your attention — and fit your skill set?

Some maintainers will mark issues that are suitable for new contributors with labels like good first issue or first-timers-only. A help wanted label is another good indication that maintainers are looking for the community’s help with an issue. You can filter issues by label in GitHub to get a view of all open issues that have been marked specifically for first time contributors.

If you’re selecting an issue that hasn’t been marked help wanted or good for first time contributors, it may be a good idea to comment on the issue to let the maintainers know you’re interested in helping out. The last thing that you want is to spend a lot of time working on a solution that the project maintainers aren’t interested in merging. Bug fixes and documentation errors are usually a pretty safe bet, but it’s always a good idea to confirm that the task you’re taking on is in line with the community’s vision.

3. Check project requirements.

Most projects will have their own set of guidelines for how contributions should be submitted. The first thing to check is the project’s license. While most open source licenses won’t cover policies on accepting contributions from the public, it is a good idea to review the software’s terms of usage in case you wish to modify or distribute the project.

The next thing to check is the repository’s CONTRIBUTING.md file. CONTRIBUTING.md contains the project’s contribution guidelines. A good set of contributor guidelines will outline the kinds of contributions that the project does and does not accept, templates for submitting pull requests or issues, and a style guide, if the project uses one.

4. Submit a pull request.

Once you’ve identified the issue that you want to tackle and put together a solution, it’s time for the main event — submitting your change to the project as a pull request. But if you’re new to GitHub, that can be an intimidating process.

The first step is to fork the project — basically, copy it over to your own GitHub account — and then clone the repository to pull down a local version to your machine. On your local copy, create a branch where you’ll make your edits. When you’re finished making edits, commit the changes and push them to your remote repository in GitHub. Then, navigate to the remote repository in your GitHub account and you’ll see a green Compare and pull request button. The next screen will autofill the base fork and branch (the one that you want to merge into) as well as the head fork and branch (the one you created, containing your proposed changes). Fill in a comment with some information about the changes you want to make (the project may even have a specific template for you to fill in), and then click the button to create the pull request. This sends your proposed changes to the maintainers to review and merge into the core project.

When you go through the process of submitting a pull request for the first time, it can feel like all eyes are on you, and the prospect of making a mistake can be nerve-wracking. For that reason, first contributions.github.io provides a test repository that new contributors can use to practice submitting a pull request. Consider it a safe zone to get comfortable with the Git workflow used to contribute to group projects.

5. What if my PR isn’t merged?

If all goes according to plan, the maintainers will merge your change and you can celebrate your first open source contribution. But what if the maintainers request edits to your pull request…or even decline to merge it?

It’s disappointing to work on a contribution only to have the maintainers say no, but open source projects also have to set some guardrails around what they will and won’t accept to keep the project on track. It’s okay to ask follow-up questions about why the decision was made, but at the end of the day, the proposed change might not be a good fit for the project or might not be general enough to support a wide variety of use cases. But, that doesn’t mean that your use case isn’t valid or that others might not benefit. You can always create a fork and take the project in your own direction — that’s the great thing about open source.

Conclusion

Getting involved with open source opens the door to a world of exciting projects and new connections, and there have never been so many resources geared toward beginners. In this post, we’ve examined some of the reasons why you might want to learn more about open source and some of the first steps you can take to get started.

As longtime open source contributors, the Brand Labs team had a few parting words of advice for new developers getting started. Carson emphasizes that contributing to open source is a two-way relationship, and it’s important for developers to see themselves as part of the solution when reporting issues: “When people are new, they almost think that it’s like a customer support system. They fill out an issue and they’re like, ‘Well, I’ve reported this problem, where are we at,’ not really understanding that you’re providing assistance to this project by recording the issue. And, really, you need to have due diligence and fill out the issue template, really look into it, and even try and solve this problem. It’s not a Customer Support Portal — it’s an open source project that everybody can contribute to.”

Serverless, AWS Lambda, Less Server?

Ritam Debnath — Fri, 01 Jul 2022 15:31:24 +0000

I have a love-hate relationship with Lambda. The service offered by AWS sparked my interest in 2014 however lack of tooling discouraged my complete adoption of the service. These days however it’s hard to find many workplaces not talking about Serverless technology and Lambda.

Photo by Brett Jordan on Unsplash
I love lambda for the following reasons:

Automatic Scaling
Minimized Costs
Ecosystem of Triggers
Rapid prototyping
The reason I hate Lambda is assumptions on:

Infinite scaling
Ease of management
First, what is Serverless? Serverless architecture is a cloud model where providers allocate resources on-demand to fulfill requests. What services are considered serverless appears to get blurrier as time goes on. My perception of what is serverless comes down to minimal fixed costs with costs scaling based on usage with minimal management of infrastructure.

But now what is Lambda? Lambda is an offering from AWS that allows for code execution without worrying about provisioning or managing servers. Lambdas have triggers to determine when the code should be executed, in most scenarios this is caused by API Gateway receiving an HTTP request. Once you dive out of just Request/Response patterns Lambda will assist in building event-driven processes.

Uh-oh, what’s event-driven? To avoid turning this article into a thousand questions, event-driven processes that utilize Lambda can be imagined as a flow diagram. Other services in AWS can trigger Lambda execution, a very common example that is shown in tutorials is whenever a file is uploaded to an S3 Bucket ( Cloud File Storage ) you can trigger a Lambda to resize the image.

A good resource if you are interested in learning how Lambda fits into the event-driven paradigm. https://docs.aws.amazon.com/lambda/latest/operatorguide/lambda-event-driven-paradigm.html

Okay, awesome we got some of the terminologies out of the way for those not familiar with Lambda. Now let’s get into the hate side of the relationship. There is a very common misconception from the buzzword Lambda and Scale that they shouldn’t expect to see any restrictions in concurrency.

Lambda does a wonderful job at offering low-cost compute when you burst concurrent requests between 0–1000. Once you reach that 1000 concurrent requests you are going to be throttled and the system needs to handle that.

I get it, your first thought is what’s the likelihood of a user requesting something from my API 1000 times at the same time. Your right it’s unlikely for small-scale products unless being targeted unethically.

This is where lambda chaining can come in and be a tad bit of a pain. Let’s say whenever a user makes a POST request to an entity we cause additional Lambdas to trigger to fetch another entity. That may take down our number of concurrent requests from 1000 to 500 assuming two lambdas are required to process a request.

Concurrency is determined at a particular point in time, there isn’t a strict per second rule but an understanding of maximum concurrency. If our third party API that we are syncing data to unfortunately takes a few seconds to return we are now further limited.

System complexity can get out of hand quickly, be conscious that relying on the convenience of Lambda for compute can land you in a situation where you are struggling to maintain below a concurrency limit.

Ease of management, now Amazon does provide a lot of amazing tools for observability and monitoring of Lambda and Serverless applications they do require a steep learning curve and aren’t baked into the service.

It’s far too common to see engineering teams utilize Lambda in an always sunny mindset. Lambda by itself doesn’t safeguard your team from making critical architecture mistakes and anti-patterns that could result in the degradation or failure of a system. Be prepared to understand what it means to measure, analyze and understand the performance of your Lambda system and not assume AWS is holding your hand.

A must-have in my opinion is Lambda Insights, it’s a set of additional metrics and aggregates available in Cloudwatch to assist in monitoring AWS Serverless applications built on Lambda. There is an additional cost to running with Enhanced Monitoring but has to be weighed up against the impact of extended downtime. Read more about Lambda Insights here https://docs.aws.amazon.com/lambda/latest/dg/monitoring-insights.html#monitoring-insights-enabling-console

I’d recommend investigating the case studies of AWS X-Ray to determine if it’s valuable for your system. https://aws.amazon.com/xray/

Please don’t take this as a don’t use Lambda story. Lambda is a powerful offering that can enable engineers to build cloud solutions. I’m always down to chat Serverless and Lambda so feel free to reach out.

I’m hoping to get a few articles together in the coming month demonstrating my thought process when developing RESTful APIs using Lambdas and some of the gotchas to look out for.

A Beginner's Guide to Machine Learning

Ritam Debnath — Fri, 01 Jul 2022 15:18:39 +0000

Should I learn now… or later? Learning is a universal skill/trait that is acquired by any living organism on this planet. Learning is defined by: the acquisition of knowledge or skills through experience, study, or by being taught.Whether that be a plant learning how to respond to light and temperature, a monkey learning how to peel a banana, or us humans learning how to ride a bike. This commonality is what makes us unique and evolve over time.

But what if I said, “Machines can learn too”

We’re in the age where machines are no different. Machine Learning is still fairly a new concept. We can teach machines how to learn and some machines can even learn on its own. This is magical phenomenon is called Machine Learning.

Targeted Audience: Beginners and/or Machine Learning Fresh Bloods

Hopefully this article will provide some useful insights and open up your mind to what computers can do now a days. I won’t go in depth about what machine learning is, but rather a high-level overview.

If there is anything that you should LEARN from reading this article, it is this:

Machines can predict the future, as long as the future doesn’t look too different from the past.

Applications of Machine Learning

Before we get started, here is a quick overview of what machine learning is capable of:

Healthcare: Predicting patient diagnostics for doctors to review
Social Network: Predicting certain match preferences on a dating website for better compatibility
Finance: Predicting fraudulent activity on a credit card
E-commerce: Predicting customer churn
Biology: Finding patterns in gene mutations that could represent cancer

“Most of the knowledge in the world in the future is going to be extracted by machines and will reside in machines” — Yann LeCun, Director of AI Research, Facebook

How Do Machines Learn?

To keep things simple, just know that machines “learn” by finding patterns in similar data. Think of data as information you acquire from the world. The more data given to a machine, the “smarter” it gets.

But not all data are the same.Imagine you’re a pirate and your life mission was to find the buried treasure somewhere in the island. In order to find the treasure, you’re going to need sufficient amount of information. Like data, this information can either lead you to the right direction or the wrong direction. The better the information/data that is obtained, the more uncertainty is reduced, and vice versa. So it’s important to keep in mind the type of data you’re giving to your machine to learn.

“More data beats better models. Better data beats more data.” — Riley Newman

Nonethless, after a sufficient amount of data is given, then the machine can make predictions. Machines can predict the future, as long as the future doesn’t look too different from the past.

Machine “learns” really by using old data to get information about whats the most likelihood that will happen. If the old data looks a lot like the new data, then the things you can say about the old data will probably be relevant to the new data. It’s like looking back to look forward.

Types of Machine Learning

Important Definition (Label): In supervised learning, the “answer” or “result” portion of an example. Each example in a labeled data set consists of one or more features and a label. For instance, in a housing data set, the features might include the number of bedrooms, the number of bathrooms, and the age of the house, while the label might be the house’s price. in a spam detection dataset, the features might include the subject line, the sender, and the email message itself, while the label would probably be either “spam” or “not spam.” -source

There are three main categories of machine learning:

Supervised learning: The machine learns from labeled data. Normally, the data is labeled by humans.
Unsupervised learning: The machine learns from un-labeled data. Meaning, there is no “right” answer given to the machine to learn, but the machine must hopefully find patterns from the data to come up with an answer.
Reinforcement learning: The machine learns through a reward-based system.

Supervised Machine Learning

Supervised learning is the most common and studied type of learning because it is easier to train a machine to learn with labeled data than with un-labeled data. Depending on what you want to predict, supervised learning can used to solve two types of problems: regression or classification.

Regression Problem:

If you want to predict continuous values, such as trying to predict the cost of a house or the weather outside in degrees, you would use regression. This type of problem doesn’t have a specific value constraint because the value could be any number with no limits.

Classification Problem:

If you’re interested in a problem like: “Am I ugly?” then this is a classification problem because you’re trying to classify the answer into two specific categories: yes or no (in this case the answer is yes to the question above). This is also called a, binary classification problem.

Unsupervised Machine Learning

Since there is no labeled data for machines to learn from, the goal for unsupervised machine learning is to detect patterns in the data and to group them. Unsupervised learning are machines trying to learn “on their own”, without help. Imagine someone throwing you piles of data and says “Here you go boy, find some patterns and group them out for me. Thanks and have fun.”

Depending on what you want to group together, unsupervised learning can group data together by: clustering or association.

Clustering Problem:

Unsupervised learning tries to solve this problem by looking for similarities in the data. If there is a common cluster or group, the algorithm would then categorize them in a certain form. An example of this could be trying to group customers based on past buying behavior.

Association Problem:

Unsupervised learning tries to solve this problem by trying to understand the rules and meaning behind different groups. Finding a relationship between customer purchases is a common example of an association problem. Stores may want to know what type of products were purchased together and could possibly use this information to organize the placement of these products for easier access. One store found out that there was a strong association between customers buying beer and diapers. They deduced from this statement that males who had went out to buy diapers for their babies also tend to buy beer as well.

Reinforcement Machine Learning

This type of machine learning requires the use of a reward/penalty system. The goal is to reward the machine when it learns correctly and to penalize the machine when it learns incorrectly.

Reinforcement Machine Learning is a subset of Artificial Intelligence. With the wide range of possible answers from the data, the process of this type of learning is an iterative step. It continuously learns.

Examples of Reinforcement Learning:

Training a machine to learn how to play (Chess, Go)
Training a machine how to learn and play Super Mario by itself
Self-driving cars

Final Notes

This is my first article and I hope you learned something! If there is anything that you guys would like to add to this article, feel free to leave a message and don’t hesitate! Any sort of feedback is truly appreciated. Don’t be afraid to share this! Thanks!

Oh yeah, since this article is about learning, here’s a free quote to keep in mind:

“Life is like riding a bicycle. To keep your balance you must keep moving.”