Setup With Pritunl

Overview

This documentation provides a comprehensive guide to setting up a Virtual Private Network (VPN) server using Pritunl, a popular open-source VPN server management platform. By following these steps, users can establish a secure and private network infrastructure suitable for various applications, such as remote access, secure communication, and data privacy.

Prerequisites

  • AWS account: Users must have an active AWS (Amazon Web Services) account to create and manage instances on the cloud platform.
  • Instance creation: An EC2 instance needs to be created in the desired region (e.g., Mumbai) using the Ubuntu 22.04 AMI. Users should ensure that ports 80, 443, and 22 are allowed in the security group settings.
  • Access to the instance: Users need SSH access to the instance created on AWS. They should possess the private key associated with the EC2 instance to establish a secure connection.
  • Web browser: A web browser, preferably Google Chrome, is required to access the Pritunl dashboard and configure the VPN server settings.
  • Pritunl client: To connect to the VPN server from client machines, users must install the Pritunl client application. The client can be installed on various operating systems, including Windows, macOS, and Linux distributions.
  • Network configuration: Users should ensure proper network configuration, including DNS settings, virtual network details, and firewall rules, to establish seamless communication between the VPN server and client machines.

Setting up a VPN Server

Step 1: Setup Instance 

  • Launch an instance in the Mumbai region using the Ubuntu 22.04 AMI.
  • Ensure ports 80, 443, and 22 are allowed in the security group.

Steps for Launching Instance

  • Select the Mumbai region.
  • Launch an instance, providing a name.
  • Choose the specified AMI.
    quick start
  • Select t2.micro instance type
  • Choose or create a key pair
  • Select the default VPC and adjust network settings if necessary
  • Allow SSH, HTTP, and HTTPS ports in the security group
  • Launch the instance

Step 2: Access the Instance and Setup VPN

  • SSH into the instance: ssh ubuntu@yourip -i "key"
  • Switch to root: sudo -i
  • Execute the following commands
Shell
 
sudo tee /etc/apt/sources.list.d/pritunl.list << EOF

deb http://repo.pritunl.com/stable/apt jammy main

EOF



# Import signing key from keyserver

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com --recv 7568D9BB55FF9E5287D586017AE645C0CF8E292A

# Alternative import from download if keyserver offline

curl https://raw.githubusercontent.com/pritunl/pgp/master/pritunl_repo_pub.asc | sudo apt-key add -



sudo tee /etc/apt/sources.list.d/mongodb-org-6.0.list << EOF

deb https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/6.0 multiverse

EOF



wget -qO - https://www.mongodb.org/static/pgp/server-6.0.asc | sudo apt-key add -



sudo apt update

sudo apt --assume-yes upgrade



# WireGuard server support

sudo apt -y install wireguard wireguard-tools



sudo ufw disable



sudo apt -y install pritunl mongodb-org

sudo systemctl enable mongod pritunl

sudo systemctl start mongod pritunl


Logging and Monitoring in AWS

Amazon Web Services (AWS) is a popular cloud platform that provides a variety of services for developing, deploying, and managing applications. It is critical to develop good logging and monitoring practices while running workloads on AWS to ensure the health, security, and performance of your cloud-based infrastructure. In this post, we will look at the significance of logging and monitoring in AWS, as well as the many alternatives and best practices for logging and monitoring, as well as prominent AWS services and tools that may help you achieve these goals.

The Importance of Logging and Monitoring in AWS

Before we dive into the technical aspects of logging and monitoring in AWS, it’s essential to understand why these activities are critical in a cloud-based environment.

AWS vs. Azure: Which Is Better for Cloud Computing?

Cloud computing first came to light during the mid-2000s, with providers like Amazon Web Services (AWS), Microsoft’s Azure, and Google Cloud Platform (GCP) taking charge. Over the years, Cloud computing has been gaining popularity and has seen exponential growth and adaptability in the last decade. In fact, the global cloud infrastructure spending reached US$247.1 Billion in 2022 and is expected to grow further by 23% in 2023.

Today, there are several service providers in the Cloud computing space with a variety of offerings such as pocket-friendly costs, easy setup options, and state-of-the-art security. As a result, more and more companies are migrating their infrastructure to Cloud platforms to take advantage of various business benefits associated with their adoption.

Web Development Is Getting Too Complex, And It May Be Our Fault

Front-end development seemed simpler in the early 2000s, didn’t it? The standard website consisted mostly of static pages made of HTML and CSS seasoned with a pinch of JavaScript and jQuery. I mean, who doesn’t miss the cross-browser compatibility days, right?

Fast forward to today, and it looks like a parallel universe is taking place with an overwhelming number of choices. Which framework should you use for a new project? Perhaps more established ones like React, Angular, Vue, Svelte, or maybe the hot new one that came out last month? Each framework comes with its unique ecosystem. You also need to decide whether to use TypeScript over vanilla JavaScript and choose how to approach server-side rendering (or static site generation) with meta-frameworks like Next, Nuxt, or Gatsby. And we can’t forget about unit and end-to-end testing if you want a bug-free web app. And we’ve barely scratched the surface of the front-end ecosystem!

But has it really gotten more complex to build websites? A lot of the frameworks and tooling we reach for today were originally crafted for massive projects. As a newcomer, it can be frightening to have so many to consider, almost creating a fear of missing out that we see exploited to sell courses and tutorials on the new hot framework that you “cannot work without.”

All this gives the impression that web development has gotten perhaps too complex. But maybe that is just an exaggeration? In this article, I want to explore those claims and find out if web development really is that complex and, most importantly, how we can prevent it from getting even more difficult than we already perceive it to be.

How It Was Before

As someone who got into web development after 2010, I can’t testify to my own experience about how web development was from the late 1990s through the 2000s. However, even fifteen years ago, learning front-end development was infinitely simpler, at least to me. You could get a website started with static HTML pages, minimal CSS for styling, and a sprinkle of JavaScript (and perhaps a touch of jQuery) to add interactive features, from toggled sidebars to image carousels and other patterns. Not much else was expected from your average developer beyond that — everything else was considered “going the extra mile.” Of course, the awesome native CSS and JavaScript features we have today weren’t around back then, but they were also unnecessary for what was considered best practice in past years.

Large and dynamic web apps certainly existed back then — YouTube and Facebook, to name a couple — but they were developed by massive companies. No one was expected to re-create that sort of project on their own or even a small team. That would’ve been the exception rather than the norm.

I remember back then, tend to worry more about things like SEO and page optimization than how my IDE was configured, but only to the point of adding meta tags and keywords because best practices didn’t include minifying all your assets, three shaking your code, caching your site on edge CDNs, or rendering your content on the server (a problem created by modern frameworks along hydration). Other factors like accessibility, user experience, and responsive layouts were also largely overlooked in comparison to today’s standards. Now, they are deeply analyzed and used to boost Lighthouse scores and impress search engine algorithms.

The web and everything around it changed as more capabilities were added and more and more people grew to depend on it. We have created new solutions, new tools, new workflows, new features, and whatever else new that is needed to cater to a bigger web with even bigger needs.

The web has always had its problems in the past that were worthy of fixing: I absolutely don’t miss tables and float layouts, along with messy DOM manipulation. This post isn’t meant to throw shade on new advances while waxing nostalgic about the good days of the “old wild web.” At the same time, though, yesterday’s problems seem infinitely simpler than those we face today.

JavaScript Frameworks

JavaScript frameworks, like Angular and React, were created by Google and Facebook, respectively, to be used in their own projects and satisfy the needs that only huge web-based companies like them have. Therein lies the main problem with web complexity: JavaScript frameworks were originally created to sustain giant projects rather than smaller ones. Many developers vastly underestimate the amount of time it takes to build a codebase that is reliable and maintainable with a JavaScript framework. However, the alternative of using vanilla JavaScript was worse, and jQuery was short for the task. Vanilla JavaScript was also unable to evolve quickly enough to match our development needs, which changed from simple informative websites to dynamic apps. So, many of us have quickly adopted frameworks to avoid directly mingling with JavaScript and its messy DOM manipulation.

Back-end development is a completely different topic, subject to its own complexities. I only want to focus on front-end development because that is the discipline that has perhaps overstepped its boundaries the most by bleeding into traditional back-end concerns.

Stacks Getting Bigger

It was only logical for JavaScript frameworks to grow in size over time. The web is a big place, and no one framework can cover everything. But they try, and the complexity, in turn, increases. A framework’s size seems to have a one-to-one correlation with its complexity.

But the core framework is just one piece of a web app. Several other technologies make up what’s known as a tech “stack,” and with the web gaining more users and frameworks catering to their needs, tech stacks are getting bigger and bigger. You may have seen popular stacks such as MEAN (MongoDB, Express, Angular, and Node) or its React (MERN) and Vue (MEVN) variants. These stacks are marketed as mature, test-proofed foundations suitable for any front-end project. That means the advertised size of a core framework is grossly underestimated because they rely on other micro-frameworks to ensure highly reliable architectures, as you can see in stackshare.io. Besides, there isn’t a one-size-fits-all stack; the best tool has always depended — and will continue to depend — on the needs and goals of your particular project.

This means that each new project likely requires a unique architecture to fulfill its requirements. Giant tech companies need colossal architectures across all their projects, and their stacks are highly engineered accordingly to secure scalability and maintenance. They also have massive customer bases, so maintaining a large codebase will be easier with more revenue, more engineers, and a clearer picture of the problem. To minimize waste, the tech stacks of smaller companies and projects can and should be minimized not only to match the scale of their needs but to the abilities of the developers on the team as well.

The idea that web development is getting too complex comes from buying into the belief that we all have the same needs and resources as giant enterprises.

Trying to imitate their mega stacks is pointless. Some might argue that it’s a sacrifice we have to make for future scalability and maintenance, but we should focus first on building great sites for the user without worrying about features users might need in the future. If what we are building is worth pursuing, it will reach the point where we need those giant architectures in good time. Cross that bridge when we get there. Otherwise, it’s not unlike wearing Shaquille O’Neal-sized sneakers in hopes of growing into them. They might not even last until then if it happens at all!

We must remember that the end-user experience is the focus at the end of the day, and users neither care about nor know what stack we use in our apps. What they care about is a good-looking, useful website where they can accomplish what they came for, not the technology we use to achieve it. This is how I’ve come to believe that web development is not getting more complex. It’s developers like us who are perpetuating it by buying into solutions for problems that do not need to be solved at a certain scale.

Let me be really clear: I am not saying that today’s web development is all bad. Indeed, we’ve realized a lot of great features, and many of them are thanks to JavaScript frameworks that have pushed for certain features. jQuery had that same influence on JavaScript for many, many years.

We can still create minimum viable products today with minimal resources. No, those might not make people smash the Like button on your social posts, but they meet the requirements, nothing more and nothing less. We want bigger! Faster! Cheaper! But we can’t have all three.

If anything, front-end development has gotten way easier thanks to modern features that solve age-old development issues, like the way CSS Flexbox and Grid have trivialized layouts that used to require complex hacks involving floats and tables. It’s the same deal with JavaScript gaining new ways to build interactions that used to take clever workarounds or obtuse code, such as having the Intersection Observer API to trivialize things like lazy loading (although HTML has gained its own features in that area, too).

We live in this tension between the ease of new platform features and the complexity of our stacks.

Do We Need A JavaScript Framework For Everything?

Each project, regardless of its simplicity, desperately needs a JavaScript framework. A project without a complex framework is like serving caviar on a paper plate.

At least, that’s what everyone seems to think. But is that actually true? I’d argue on the contrary. JavaScript frameworks are best used on bigger applications. If you’re working on a smaller project, a component-based framework will only complicate matters, making you split your website into a component hierarchy that amounts to overkill for small projects.

The idea of needing a framework for everything has been massively oversold. Maybe not directly, but you unconsciously get that feeling whenever a framework’s name pops in, as Edge engineer Alex Russell eloquently expresses in his article, “The Market For Lemons”:

“These technologies were initially pitched on the back of “better user experiences” but have utterly failed to deliver on that promise outside of the high-management-maturity organisations in which they were born. Transplanted into the wider web, these new stacks have proven to be expensive duds.”

— Alex Russell

Remember, the purpose of a framework is to simplify your life and save time. If the project you’re working on is smaller, the time you supposedly save is likely overshadowed by the time you spend either setting up the framework or making it work with the rest of the project. A framework can help make bigger web apps more interactive and dynamic, but there are times when a framework is a heavy-handed solution that actually breeds inefficient workflows and introduces technical debt.

Step back and think about this: Are HTML, CSS, and a touch of JavaScript enough to build your website or web application? If so, then stick with those. What I am afraid of is adding complexity for complexity’s sake and inadvertently raising the barrier to entry for those coming into web development. We can still accomplish so much with HTML and CSS alone, thanks again to many advances in the last decade. But we give the impression that they are unsuitable for today’s web consumption and need to be enhanced.

Knowing Everything And Nothing At The Same Time

The perceived standard that teams must adopt framework-centered architectures puts a burden not only on the project itself but on a developer’s well-being, too. As mentioned earlier, most teams are unable to afford those architectures and only have a few developers to maintain them. If we undermine what can be achieved with HTML and CSS alone and set the expectations that any project — regardless of size — needs to have a bleeding edge stack, then the weight to meet those expectations falls on the developer’s shoulders, with the great responsibility of being proficient in all areas, from the server and database to front end, to design, to accessibility, to performance, to testing, and it doesn’t stop. It’s what has been driving “The Great Divide” in front-end development, which Chris Coyier explains like this:

“The divide is between people who self-identify as a (or have the job title of) front-end developer yet have divergent skill sets. On one side, an army of developers whose interests, responsibilities, and skillsets are heavily revolved around JavaScript. On the other, an army of developers whose interests, responsibilities, and skillsets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, and so on.”

— Chris Coyier

Under these expectations, developers who focus more on HTML, CSS, design, and accessibility rather than the latest technology will feel less valued in an industry that appears to praise those who are concerned with the stack. What exactly are we saying when we start dividing responsibilities in terms of “full-stack development” or absurd terms like “10x development”? A while back, Brad Frost began distinguishing these divisions as “front-of-the-front-end” and “back-of-the-front-end”.

Mandy Michael explains what impact the chase for “full-stack” has had on developers trying to keep up:

“The worst part about pushing the “know everything” mentality is that we end up creating an industry full of professionals suffering from burnout and mental illness. We have people speaking at conferences about well-being, imposter syndrome, and full-stack anxiety, yet despite that, we perpetuate this idea that people have to know everything and be amazing at it.”

— Mandy Michael

This isn’t the only symptom of adopting heavy-handed solutions for what “vanilla” HTML, CSS, and JavaScript already handle nicely. As the expectations for what we can do as front-end developers grow, the learning curve of front-end development grows as well. Again, we can’t learn and know everything in this vast discipline. But we tell ourselves we have to, and thanks to this mentality, it’s unfortunately common to witness developers who may be extremely proficient with a particular framework but actually know and understand little of the web platform itself, like HTML semantics and structure.

The fact that many budding developers tend to jump straight into frameworks at the expense of understanding the basics of HTML and CSS isn’t a new worry, as Rachel Andrew discussed back in 2019:

“That’s the real entry point here, and yes, in 2019, they are going to have to move on quickly to the tools and techniques that will make them employable, if that is their aim. However, those tools output HTML and CSS in the end. It is the bedrock of everything that we do, which makes the devaluing of those with real deep skills in those areas so much more baffling.”

— Rachel Andrew

And I want to clarify yet again that modern Javascript frameworks and libraries aren’t inherently bad; they just aren’t designed to replace the web platform and its standards. But we keep pushing them like we want them to!

The Consequences Of Vendor Lock-In

“Vendor lock-in” happens when we depend too deeply on proprietary products and services to the extent that switching to other products and services becomes a nearly impossible task. This often occurs when cloud services from a particular company are deeply integrated into a project. It’s an issue, especially in cloud computing, since moving databases once they are set up is expensive and lengthy.

Vendor lock-in in web development has traditionally been restricted to the back end, like with cloud services such as AWS or Firebase; the front-end framework, meanwhile, was a completely separate concern. That said, I have noticed a recent trend where vendor lock-in is reaching into meta-frameworks, too. With the companies behind certain meta-frameworks offering hosting services for their own products, swapping hosts is increasingly harder to do (whether the lock-in is designed intentionally or not). Of course, companies and developers will be more likely to choose the hosting service of the company that made a particular framework used on their projects — they’re the experts! — but that only increases the project’s dependency on those vendors and their services.

A clear example is the relationship between Next and Vercel, the parent cloud service for Next. With the launch of Next 13, it has become increasingly harder to set up a Next project outside of Vercel, leading to projects like Open Next, which says right on its website that “[w]hile Vercel is great, it’s not a good option if all your infrastructure is on AWS. Hosting it in your AWS account makes it easy to integrate with your backend [sic]. And it’s a lot cheaper than Vercel.” Fortunately, the developers’ concerns have been heard, and Next 14 brings clarity on how to self-host Next on a Node server.

Another example is Gatsby and Gatsby Cloud. Gatsby has always offered helpful guides and alternative hosting recommendations, but since the launch of Gatsby Cloud in 2019, the main framework has been optimized so that using Gatsby and Gatsby Cloud together requires no additional hosting configurations. That’s fantastic if you adopt both, but it’s not so great if all you need is one or the other because integrating the framework with other hosts — and vice versa — is simply harder. It’s as if you are penalized for exercising choice.

And let’s not forget that no team expected Netlify to acquire Gatsby Cloud in February 2023. This is a prime case where the vendor lock-in problem hits everybody because converting from one site to another comes at a cost. Some teams were charged 120% more after converting from Gatsby Cloud to Netlify — even with the same plan they had with Gatsby Cloud!

What’s the solution? The common answer I hear is to stop using paid cloud services in favor of open-sourced alternatives. While that’s great and indeed a viable option for some projects, it fails to consider that an open-source project may not meet the requirements needed for a given app.

And even then, open-source software depends on the community of developers that maintain and update the codebase with little to no remuneration in exchange. Further, open source is equally prone to locking you into certain solutions that are designed to solve a deficiency with the software.

There are frameworks and libraries, of course, that are in no danger of being abandoned. React is a great example because it has an actively engaged community behind it. But you can’t have the same assurance with each new dependency you add to a project. We can’t simply keep installing more packages and components each time we spot a weak spot in the dependency chain, especially when a project is perfectly suited for a less complex architecture that properly leverages the web platform.

Choosing technology for your stack is an exercise of picking your own poison. Either choose a paid service and be subject to vendor lock-in in the future, or choose an open-source one and pray that the community continues to maintain it.

Those are virtually the only two choices. Many of the teams I know or have worked on depend on third-party services because they cannot afford to develop them on their own; that’s a luxury that only massive companies can afford. It’s a problem we have to undergo when starting a new project, but one we can minimize by reducing the number of dependencies and choosing wisely when we have to.

Each Solution Introduces A New Problem

Why exactly have modern development stacks gotten so large and complex? We can point a finger at the “Development Paradox.” With each new framework or library, a new problem crops up, and time-starved developers spend months developing a new tool to solve that problem. And when there isn’t a problem, don’t worry — we will create one eventually. This is a feedback loop that creates amazing solutions and technologies but can lead to over-engineered websites if we don’t reign it in.

This reminds me of the famous quote:

“The plain fact is that if you don’t have a problem, you create one. If you don’t have a problem, you don’t feel that you are living.”

— U.G. Krishnamurti

Let’s look specifically at React. It was originally created by Facebook for Facebook to develop more dynamic features for users while improving Facebook’s developer experience.

Since React was open-sourced in 2013 (and nearly re-licensed in 2017, if it weren’t for the WordPress community), hundreds of new utilities have been created to address various React-specific problems. How do you start a React project? There’s Create React App and Vite. Do you need to enhance your state management? There is Redux, among other options. Need help creating forms? There is a React Hook Form. And perhaps the most important question: Do you need server-side rendering? There’s Next, Remix, or Gatsby for that. Each solution comes with its own caveats, and developers will create their own solutions for them.

It may be unfair to pick on React since it considers itself a library, not a framework. It’s inevitably prone to be extended by the community. Meanwhile, Angular and Vue are frameworks with their own community ecosystems. And this is the tip of the iceberg since there are many JavaScript frameworks in the wild, each with its own distinct ideology and dependencies.

Again, I don’t want you to get the wrong idea. I love that new technologies emerge and find it liberating to have so many options. But when building something as straightforward as a webpage or small website — which some have started referring to as “multi-page applications” — we have to draw a line that defines how many new technologies we use and how reliable they are. We’re quite literally mashing together third-party code written by various third-party developers. What could go wrong? Please don’t answer that.

Remember that our users don’t care what’s in our stacks. They only see the final product, so we can save ourselves from working on unnecessary architectures that aren’t appreciated outside of development circles. It may seem counterintuitive in the face of advancing technology, but knowing that the user doesn’t care about what goes behind the scenes and only sees the final product will significantly enhance our developer experience and free you from locked dependencies. Why fix something that isn’t broken?

How Can We Simplify Our Codebases?

We’ve covered several reasons why web development appears to be more complex today than in years past, but blaming developers for releasing new utilities isn’t an accurate portrayal of the real problem. After all, when developing a site, it’s not like we are forced to use each new technology that enters the market. In fact, many of us are often unaware of a particular library and only learn about it when developing a new feature. For example, if we want to add toast notifications to our web app, we will look for a library like react-toastify rather than some other way of building them because it “goes with” that specific library. It’s worth asking whether the app needs toast notifications at all if they introduce new dependencies.

Imagine you are developing an app that allows users to discover, review, and rate restaurants in their area. The app needs, at a bare minimum, information about each restaurant, a search tool to query them, and an account registration flow with authentication to securely access the account. It’s easy to make assumptions about what a future user might need in addition to these critical features. In many cases, a project ends up delayed because we add unnecessary features like SSR, notifications, offline mode, and fancy animations — sometimes before the app has even converted its first registered user!

I believe we can boil down the complexity problem to personal wishes and perceived needs rather than properly scoping a project based on user needs and experiences.

That level of scope creep can easily turn into an over-engineered product that will likely never see the light of launching.

What can we do to simplify our own projects? The following advice is relevant when you have control over your project, either because it’s a personal one, it’s a smaller one for a smaller team, or you have control over the decisions in whatever size organization you happen to be in.

The hardest and most important step is having a sense of detection when your codebase is getting unnecessarily complicated. I deem it the hardest step because there is no certainty of what the requirements are or what the user needs; we can only make assumptions. Some are obvious, like assuming the user will need a way to log into the app. Others might be unclear, like whether the app should have private messaging between users. Others are still far-fetched, like believing users need extremely low latency in an e-commerce page. Other features are in the “nice to have” territory.

That is regarding the user experience, but the same questions emerge on the development side:

  • Should we be using a CSS preprocessor or a CSS framework, or can we achieve it using only CSS modules?
  • Is vanilla JavaScript enough, or are we going to add TypeScript?
  • Does the app need SSR, SSG, or a hybrid of the two?
  • Should we implement Redis on the back end for faster database queries, or is that too much scope for the work?
  • Should we be implementing end-to-end testing or unit tests?

These are valid questions that should be considered when developing a site, but they can distract us from our main focus: getting things done.

“Done is better than perfect.”

— Sheryl Sandberg

And, hey, even the largest and most sophisticated apps began as minimal offerings that iterated along the way.

We also ought to be asking ourselves what would happen if a particular feature or dependency isn’t added to the project. If the answer is “nothing,” then we should be shifting our attention to something else.

Another question worth asking: “Why are we choosing to add [X]?” Is it because that’s what is popular at the moment, or because it solves a problem affecting a core feature? Another aspect to take into consideration is how familiar we are with certain technologies and give preference to those we know and can start using them right away rather than having to stop and learn the ins and outs of a new framework.

Choose the right tool for the job, which is going to be the one that meets the requirements and fits your mental model. Focus less on a library’s popularity and scalability but rather on getting your app to the point where it needs to scale in the first place.

Conclusion

It’s incredibly difficult to not over-engineer web apps given current one-size-fits-all and fear-of-missing-out mentalities. But we can be more conscious of our project goals and exercise vigilance in guarding our work against scope creep. The same can be applied to the stack we use, making choices based on what is really needed rather than focusing purely on what everyone else is using for their particular work.

After reading the word “framework” exactly 48 times in this article, can we now say the web is getting too complex? It has been complex by nature since its origins, but complexity doesn’t translate to “over-engineered” web apps. The web isn’t intrinsically over-engineered, and we only have ourselves to blame for over-engineering our projects with overly-wrought solutions for perceived needs.

Enhancing Resiliency: Implementing the Circuit Breaker Pattern for Strong Serverless Architecture on AWS

Serverless architecture is a way of building and running applications without the need to manage infrastructure. You write your code, and the cloud provider handles the rest - provisioning, scaling, and maintenance. AWS offers various serverless services, with AWS Lambda being one of the most prominent. When we talk about "serverless," it doesn't mean servers are absent. Instead, the responsibility of server maintenance shifts from the user to the provider. This shift brings forth several benefits:

  • Cost-efficiency: With serverless, you only pay for what you use. There's no idle capacity because billing is based on the actual amount of resources consumed by an application.
  • Scalability: Serverless services automatically scale with the application's needs. As the number of requests for an application increases or decreases, the service seamlessly adjusts.
  • Reduced operational overhead: Developers can focus purely on writing code and pushing updates, rather than worrying about server upkeep.
  • Faster time to market: Without the need to manage infrastructure, development cycles are shorter, enabling more rapid deployment and iteration.

Importance of Resiliency in Serverless Architecture

As heavenly as serverless sounds, it isn't immune to failures. Resiliency is the ability of a system to handle and recover from faults, and it's vital in a serverless environment for a few reasons:

Running Legacy SAP Versions on AWS

As AWS is widely adopted across the globe for deploying SAP, one of the key challenges observed is to deploy the SAP versions on AWS that are out of maintenance; some of these application versions also have no support from SAP and AWS for a deployment on cloud in specific cases. There are various mechanisms that can still be used, including the modernization option for moving to the AWS platform. The possible options and their pros and cons are evaluated in this article.

What are Legacy Versions? SAP has been an industry-leading ERP software and has been in use for close to 50 years now. The versions have evolved in these years, and while many customers keep up with the pace of innovations, there are many of them who are unable to upgrade owing to logistics, costs, and various other reasons. The flagship SAP product, SAP ERP 6.0, was released as a successor of the previous R/3 releases, in the year 2005, and this product suite ends its support in December 2025 with some latest versions supported until December 2027. In line with SAP's strategy, AWS provides support for all the ERP products, and technically, this is based on the underlying SAP Kernel as well as the corresponding Operating System and Database Version. The term legacy in this context is used for any SAP version that is older than the ones currently supported together by SAP and AWS ( as described in SAP Note 1656099, me.sap., login required).

Using IAM Authentication for Redis on AWS

Amazon MemoryDB for Redis has supported username/password-based authentication using Access Control Lists since the very beginning. But you can also use IAM-based authentication that allows you to associate IAM users and roles with MemoryDB users so that applications can use IAM credentials to authenticate to the MemoryDB cluster. With this authentication method, you don't need to use a (long-lived) user password. Instead, you use an authentication token generated using AWS Signature Version 4.

There are many benefits to this approach. Instead of managing username and password-based credentials, you can use IAM to centrally manage access to MemoryDB clusters. For client applications running on Amazon EC2, Amazon EKS, AWS Lambda, AWS App Runner, etc., you can inject these credentials (depending on the platform e.g. profile credentials in EC2 and instance role in App Runner) - this provides greater security.

Monitoring Applications at Scale in AWS

The Problem

There are various scenarios when we choose to deploy our applications in different AWS accounts:

  1. There are multiple microservices deployed in different AWS accounts in different regions based on the use case.
  2. For an organization, there could be multiple AWS accounts configured that will deploy related/unrelated services.
  3. One AWS account, one AWS region, etc.

AWS provides local metrics and monitoring via AWS CloudWatch. But things will get complicated when we need to monitor multiple applications from all these accounts to extrapolate and make decisions based on the metrics.

Serverless Image Generation Application Using Generative AI on AWS

Whether it's crafting personalized content or tailoring images to user preferences, the ability to generate visual assets based on a description is quite powerful. But text-to-image conversion typically involves deploying an end-to-end machine learning solution, which is quite resource-intensive. What if this capability was an API call away, thereby making the process simpler and more accessible for developers?

This tutorial will walk you through how to use AWS CDK to deploy a Serverless image generation application implemented using AWS Lambda and Amazon Bedrock, which is a fully managed service that makes base models from Amazon and third-party model providers (such as Anthropic, Cohere, and more) accessible through an API. Developers can leverage leading foundation models through a single API while maintaining the flexibility to adopt new models in the future.

Build a Serverless Application for Entity Detection on AWS

In this blog post, you will learn how to build a Serverless solution for entity detection using Amazon Comprehend, AWS Lambda, and the Go programming language.

Text files uploaded to Amazon Simple Storage Service (S3) will trigger a Lambda function which will further analyze it, extract entity metadata (name, type, etc.) using the AWS Go SDK, and persist it to an Amazon DynamoDB table. You will use Go bindings for AWS CDK to implement "Infrastructure-as-code" for the entire solution and deploy it with the AWS Cloud Development Kit (CDK) CLI.

AWS vs. Azure vs. Google Cloud: Comparing the Top Cloud Providers

Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) together cover 67 percent of the cloud computing market share worldwide. Better services, superior technical assistance, global presence, and vast experience in managing cloud infrastructure are the key reasons behind their growing popularity in the corporate world. This post will compare AWS vs. Azure vs. Google Cloud from different perspectives.

As an entrepreneur or a business owner, you need a dependable cloud provider to offer more flexibility and scalability to your company. We will see the differences between AWS vs. Google Cloud vs. Microsoft Azure in this post, and it will help you select the right cloud provider for your company. Even if you think of working with all three cloud service providers, you can get insight about the right vendor for specific services by reading this post.

How to Design an AI-Based Enterprise Search in AWS

Finding right information at the right moment is a key distinguisher in today's modern organization. This not only saves huge time and effort but boosts customer satisfaction as well as employee productivity. However, in most large organizations, all the contents and information are scattered and not indexed and organized properly. Often employees and customers browse through unrelated links for hours when they look for some urgent information (e.g., product information or process flows or policies, etc.) in the company's portal or intranet. Popular content management (CMS) software or wikis like Confluence or document management repositories like SharePoint lack the perfect intelligent search capabilities resulting in inefficiency as they only use the partial or full-text search based on keyword matching ignoring the semantic meaning of what the user is looking for.

Also, the traditional search doesn't understand if the question is being asked in natural language. It treats all words as search queries and tries to match all documents or contents based on that. For example, if I need to find which floor our IT helpdesk is located in my office building and simply search "Where is the IT Helpdesk located?" in general, CMS or Wiki software powering the company intranet it may bring up all links or texts matching every word of my question including "IT," "Helpdesk" as well as "located.” This would waste employee productivity, time, and morale as he or she would be spending a long time identifying correct info.

How To Build a Cross-Platform Interactive Poll Application With .NET and AWS

This story started back in December 2021 at the first post-COVID AWS re: Invent conference. We were staffed at the Welcome Desk of the AWS Developer Community Lounge. The first few minutes were awkward when people started to flow in. People were walking in front of the Welcome desk, and as soon as we made eye contact, they walked away in the opposite direction. An idea came over us; we were missing an icebreaker activity. We started mini-polls at the Welcome desk asking attendees about their favorite programming language, favorite swag, favorite AWS service, etc. Below is a picture of how we utilized the Welcome desk to poll attendees.

As we are always looking at improving our customers' experience, we quickly imagined how we could enhance the setup. Questions like "What if people could vote on touch screens and see poll results in real-time" popped up. We ended up with this mock-up of the vision we had.

Windows Clusters for SAP on AWS

The SAP Enterprise customers have strict availability requirements and to meet these KPIs, architects look up to clustering solutions to meet the requirements. The Windows Server Failover Cluster (WSFC) is one such cluster solution. It's available as part of Windows Server Datacenter edition deployments. This makes it a default choice for setups that are using Windows Servers. 

Note that the SAP HANA database is only currently released for Linux (SUSE and RHEL). Hence in such setups, the WSFC can be used for SAP Central Services (ASCS/SCS). For MS-SQL deployments, the WSFC is also used to provide high availability with SQL Always On. 

Build a Serverless Application To Automate Invoice Processing on AWS

In this blog post, you will learn how to build a serverless solution for invoice processing using Amazon Textract, AWS Lambda, and the Go programming language. Invoices and expense receipt images uploaded to Amazon S3 will trigger a Lambda function which will extract invoice metadata (ID, date, amount, etc.) using the AWS Go SDK and persist it to an Amazon DynamoDB table. You will also use Go bindings for AWS CDK to implement "Infrastructure-as-code" for the entire solution and deploy it with the AWS Cloud Development Kit (CDK) CLI.

The code is available on GitHub.

Migrating FileNet Into AWS Cloud and Migrating FileNet Security Into AWS Cloud

FileNet is an enterprise content management system designed to help organizations manage and store large amounts of content, including documents, images, and multimedia files. AWS is a cloud computing platform providing a wide range of infrastructure services, including computing, storage, and database. Migrating FileNet to the AWS Cloud can offer several benefits, including increased scalability, availability, and security. Here are some general steps that can be taken to migrate FileNet to AWS Cloud:

  • Assess current FileNet environment: Assess the current FileNet environment to determine the scope and complexity of the migration. Identify any dependencies or integrations that may need to be considered during the migration.
  • Choose the appropriate AWS services: Determine the proper AWS services that will be used to support the FileNet environment. AWS services such as Amazon Relational Database Service (RDS), Amazon Simple Storage Service (S3), and Amazon Elastic Compute Cloud (EC2) can be used to host FileNet components such as Application Servers, Content Engine, and databases.
  • Plan for data migration: Develop a plan for migrating data to the AWS environment. Data migration can be achieved through methods such as AWS DataSync or AWS Snowball.
  • Configure the environment: Configure the AWS environment to support FileNet. This may involve creating a virtual private cloud (VPC), subnets, security groups, and configuring the network.
  • Install and configure FileNet: Install and configure FileNet components such as Application Servers, Content Engine, and databases. Ensure that the FileNet environment is integrated with AWS services such as Amazon S3 and Amazon RDS.
  • Test and validate the environment: Test and validate the FileNet environment to ensure that it is functioning correctly. Perform load testing to ensure that the environment can handle expected traffic.
  • Monitor and optimize the environment: Implement monitoring tools and processes to ensure that the environment is performing optimally. Optimize the environment as needed to ensure that it continues to meet the needs of the organization.

Security is a critical factor in FileNet, and migrating FileNet security to AWS involves implementing security measures appropriate for the AWS environment. Here are some general steps that can be taken to migrate FileNet security to AWS:

Get an In-Depth Look at the Best Ways To Store Application Parameters in AWS

Many applications are now being hosted on public cloud platforms, and it becomes imperative to leverage the cloud to store their data and application parameters. And of the most popular cloud providers, Amazon Web Services (AWS) is the most widely used. While AWS offers many solutions for storing application parameters, understanding which option best fits your application and use case can be difficult. In this article, we’ll dive into the best ways to store your application parameters in AWS.

Overview of Application Properties Storage

Let us take the example of AWS Lambda — a popular compute service that allows developers to run code without provisioning or managing servers. When writing code for Lambda functions, it's common to use configuration properties to define how the function should operate. Configuration properties can include things like environment variables, database connection strings, and other settings that are specific to your application.

Step-By-Step Guide To Building a Serverless Text-to-Speech Solution Using Golang on AWS

The field of machine learning has advanced considerably in recent years, enabling us to tackle complex problems with greater ease and accuracy. However, the process of building and training machine learning models can be a daunting task, requiring significant investments of time, resources, and expertise. This can pose a challenge for many individuals and organizations looking to leverage machine learning to drive innovation and growth.

That's where pre-trained AI Services come in and allow users to leverage the power of machine learning without having extensive machine learning expertise and needing to build models from scratch - thereby making it more accessible for a wider audience. AWS machine learning services provide ready-made intelligence for your applications and workflows and easily integrate with your applications. And, if you add Serverless to the mix, well, that's just icing on the cake, because now you can build scalable and cost-effective solutions without having to worry about the backend infrastructure.