DEV Community: Murtaza 🐳

AWS+SAP: AWS Cognito and JWT w/ Exposed RFC in REST

Murtaza 🐳 — Sat, 11 Feb 2023 06:29:07 +0000

_Note; This is technically part 2 focusing more on how to configure AWS Cognito to work with SAP API Management; if you are interested in SAP API Management and policies, go here

One of our customers who run SAP workloads on Amazon Web Services (AWS) was interested in reviewing how to integrate their user pool securely with a backend-exposed RFC without putting anything at risk. To help shed light on the matter, we decided to dive into the topic and put together this blog post. The post will discuss best practices for securely integrating a user pool with an exposed RFC for those running SAP workloads on AWS. This post is suitable for both seasoned SAP professionals and beginners.

Securely integrating a user pool with an exposed RFC is crucial for organizations running SAP workloads on AWS. Amazon Web Services (AWS) offers various services that can be leveraged to secure the integration process, but it can take time to determine the best approach. In this blog post, we’ll focus on using AWS Cognito and JSON Web Tokens (JWT) to secure the integration between a user pool and an exposed RFC in REST.

AWS Cognito:

AWS Cognito is a user management and authentication service that provides sign-up and sign-in functionality for web and mobile applications. It integrates with other AWS services, including AWS AppSync, AWS Lambda, and AWS Identity and Access Management (IAM). Cognito provides a secure and scalable solution for user authentication, which is essential for ensuring your integration’s security.

JSON Web Tokens (JWT):

JWT is a compact, URL-safe means of representing claims to be transferred between two parties. JWT tokens contain encoded information, including user identity, which can be used to authenticate the user and authorize access to the application or API. JWT tokens are signed, ensuring the token’s authenticity and integrity. Using JWT tokens, you can securely authenticate a user and grant access to the exposed RFC without risking the user’s credentials.

Integration Steps:

Create a user pool in AWS Cognito and configure the necessary settings,
Create a REST API endpoint in SAP API Management to expose the RFC wrapped using SAP Cloud Integration for request and response transformation,
Secure the REST API endpoint in SAP API Management using the AWS Cognito certificate and configure the necessary authorization policies.
Pass the JWT token in the request header when accessing the exposed RFC.
Validate the JWT token in SAP API Management Policies.
Grant or deny access to the exposed RFC based on the validation result.

Let us go through the flow shown in the diagram above;

The user sends a request to the Commerce Storefront with a valid username and password.
The server authenticates the user and creates a unique JWT token with help from Cognito.
The server sends the JWT token back to the user.
The user then stores the JWT token in their local storage.

The user retrieves some details from the exposed RFC and sends the SAP API Management with the JWT token.
The server verifies the JWT token and grants access to the requested resource.

How to configure AWS Cognito;

Create a user pool

Configure the Password policy AWS has options to provide enhanced security settings for passwords, also to force MFA or not;

With what recovery options to set. Next, you configure the sign-in experience to suit your environment best; since this is a POC and we are developers, we would more or less play with the API(s) and wouldn’t be too worried about that now.

Name your user pool

Important step;

We do not require Hosted UI for login and sign-up pages since everything will be taken by our Commerce Platform using API(s) to communicate with AWS Cognito. Our Storefront will not save any secrets since that is how security incidents occur. CHOOSE Public client — Browser — Cognito API requests are made from the user systems that are not trusted with client secrets.

Enable the above user flows to enable API calls from our storefront.

The user pool was successfully created.

Extract the signing certificate;

Copy and download this certificate because SAP APIM will use this to validate the JWT tokens sent in requests.

Populate the user pool with a demo user; we will take this a little ahead to verify if the user pool is configured correctly.

When we create the user, we will be asked to force change the password to confirm the user; since we do not have hosted UI or anything, this could prove tricky for the uninitiated.

Call the API to retrieve the Token;

curl --location --request POST 'https://cognito-idp.{{AWS_REGION}}.amazonaws.com/{{USER_POOL_ID}}' \
--header 'X-Amz-Target: AWSCognitoIdentityProviderService.InitiateAuth' \
--header 'Content-Type: application/x-amz-json-1.1' \
--header 'Accept-Language: application/json' \
--data-raw '{ 
    "AuthParameters": 
    { 
        "USERNAME": "{{cognitoUserName}}",
        "NEW_PASSWORD": "{{cognitoUserPassword}}"
    }, 
    "AuthFlow": "USER_PASSWORD_AUTH",
    "ClientId": "{{cognitoClientId}}" 
}'

To confirm when you call the API to request the JWT Token, you will be struck with this body;

{
    "ChallengeName": "NEW_PASSWORD_REQUIRED",
    "ChallengeParameters": {
        "USER_ID_FOR_SRP": "1a691d76-90f0-3632-b43f-432bbc3c9521",
        "requiredAttributes": "[]",
        "userAttributes": "{\"email\":\"qazi.murtaza@faircg.com\"}"
    },
    "Session": "AYABeP7KqCHXG4jBT-qEaysPJVsAHQABAAdTZXJ2aWNlABBDb2duaXRvVXNlclBvb2xzAAEAB2F3cy1rbXMAS2Fybjphd3M6a21zOnVzLWVhc3QtMTo3NDU2MjM0Njc1NTU6a2V5L2IxNTVhZmNhLWJmMjktNGVlZC1hZmQ4LWE5ZTA5MzY1M2RiZQC4AQIBAHiG0oCCDoro3IaeecGyxCZJOVZkUqttbPnF4J7Ar-5byAHO9OhZAb2T4rq0VCQMI_JOAAAAfjB8BgkqhkiG9w0BBwagbzBtAgEAMGgGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQM9uEKK3DcQe221qK4AgEQgDvVSvNMuXn8bkUQZm4g43xJN-o3LgAEUkUIqIrdhsggrTD4z9EvydNHKGTDAvgByNcDioFr-Dfkd9A0iAIAAAAADAAAEAAAAAAAAAAAAAAAAABx02tlgAn--Caj8aCy95pA _____ wAAAAEAAAAAAAAAAAAAAAEAAADVbgpubnsc-3rD1_9E6S-ahI0xjKa43e4KkLI_V2NsmAPMyHF5D73_rdUrl0XwhtKKN1qmz7WgYWwwRiaN3DQcAWB9Oa_ubLnuif2nRw_PZZx705iVCfgEs79B1rIxxEl9KC8wE6fawCMm-WgqUUqSG_5QP3jHDSQspY_Hb4hsI1qv9pPL3Ju81OfcbPwf0mnR5nk4DMXzwNzm9c5_nSHuzJejqunMEh7xAPI7q0kdL6z17BPmgPGhgTc29nheuBNt9pMgDPQ94kLV34cFfH7F78ZkMkObdjsKXm_wdrqqZCYtxx5BIg"
}

Don’t fret; call this below request to reset the password and you will be golden. Note the headers; they are important.

curl --location --request POST 'https://cognito-idp.{{AWS_REGION}}.amazonaws.com/{{USER_POOL_ID}}' \
--header 'X-Amz-Target: AWSCognitoIdentityProviderService.RespondToAuthChallenge ' \
--header 'Content-Type: application/x-amz-json-1.1' \
--header 'Accept-Language: application/json' \
--data-raw '{
    "ChallengeName": "NEW_PASSWORD_REQUIRED",
    "ChallengeResponses": {
        "USERNAME": "{{cognitoUserName}}",
        "NEW_PASSWORD": "{{cognitoUserPassword}}"
    },
    "ClientId": "{{cognitoClientId}}",
    "Session": "AY....Insert the session recieved in the preceeding call"
}'

Calling the first API again would wield the JWT Token with a 200 OK response.

{
    "AuthenticationResult": {
        "AccessToken": "e....yJraWQ.",
        "ExpiresIn": 3600,
        "IdToken": "eyJraWQiO...",
        "RefreshToken": "eyJjdHk....",
        "TokenType": "Bearer"
    },
    "ChallengeParameters": {}
}

Verify the token at JWT.IO;

How to configure SAP API Management for JWT ; read here.

Conclusion

In conclusion, using AWS Cognito and JWT tokens is a secure and effective way to integrate a user pool with an exposed RFC for organizations running SAP workloads on AWS. By following the steps outlined in this post, you can ensure that your integration is secure and free from risk. Whether you’re a seasoned SAP professional or just starting, we hope this post has provided valuable information and insights into the best practices for securing your integration.

how to JWT with SAP API Management

Murtaza 🐳 — Sat, 11 Feb 2023 06:16:20 +0000

SAP API Management is a cloud-based, API-first platform for developing and managing APIs. It enables organizations to securely expose data, systems, and services from SAP and other sources. With SAP API Management, companies can leverage their existing investments in SAP and non-SAP systems while providing a unified, modern API layer to build, scale, and manage their APIs. This comprehensive approach to API management empowers organizations to accelerate their digital transformation and create new business opportunities.

What is JWT?

JSON Web Token (JWT) is an open standard for securely transmitting information (e.g., authentication claims) between two parties. It is a compact and self-contained way of representing data, usually in the form of a JSON object. JWT is often used in web applications and API authentication, allowing users to transfer data using tokens securely. JWT tokens are signed with a secret key, ensuring that the data is not tampered with during transport. JWT is becoming increasingly popular due to its simplicity and flexibility, as it can be used in various scenarios where secure information exchange is needed.

The below diagram demonstrates architectural implementation;

SAP API Management using JWT

Our next question would be; What purpose does an Identity provider serve?

An identity provider (IdP) is a service or system that provides users with secure access to applications and other services in a single sign-on environment. It is responsible for authenticating and authorizing user access. It is used to manage user identities and their access to applications securely. Additionally, it can provide single sign-on (SSO) access to multiple applications or websites, allowing users to log in once and securely access multiple services without needing multiple logins.

Let us go through the flow shown in the diagram above;

The user sends a request to the IdP with a valid username and password.
The server authenticates the user and creates a unique JWT token.
The server sends the JWT token back to the user.
The user then stores the JWT token in their local storage.
The user requests the SAP API Management with the JWT token.
The server verifies the JWT token and grants access to the requested resource.

Some examples of IdP are;

Amazon Cognito
SAP Customer Data Cloud
Auth0

What happens inside SAP API Management?

Multiple policies are used which are available out of the box in SAP API Management,

SAPI API Management Proxy Pre-Flow

Extract JWT policy is used to retrieve the JWT token and store it in a variable for later use,

<!-- Extract content from the request or response messages, including headers, URI paths, JSON/XML payloads, form parameters, and query parameters -->
<ExtractVariables async="true" continueOnError="false" enabled="true" xmlns='http://www.sap.com/apimgmt'>
 <!-- the source variable which should be parsed -->
 <Source clearPayload="false">request</Source>
 <!-- Specifies the XML-formatted message from which the value of the variable will be extracted -->
    <Header name="Authorization">
        <Pattern ignoreCase="true">Bearer {jwt}</Pattern>
    </Header>
 <VariablePrefix>inbound</VariablePrefix>
</ExtractVariables>

Verify JWT policy is used to verify the token against the certificate saved in the policy initially retrieved when implementing the API Proxy, this can also be retrieved by key-value pair but for this implementation, we did not overcomplicate it.

<!-- Verify JWT TOken -->
<VerifyJWT async="false" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
<Algorithm>RS256</Algorithm>
<Source>inbound.jwt</Source>
<PublicKey>
  <Value>
    -----BEGIN CERTIFICATE-----
                -----END CERTIFICATE-----
        </Value>
</PublicKey>
<!--<Subject>subject-subject</Subject>-->
<Issuer>https://dev-xxxx.au.auth0.com/</Issuer>
<Audience>https://dev-xxxx.au.auth0.com/api/v2/</Audience>
<!--<AdditionalClaims>-->
<!-- <Claim name="additional-claim-name" type="string">additional-claim-value-goes-here</Claim>-->
<!--</AdditionalClaims>-->
</VerifyJWT>

decode JWT policy decodes the token to a JSON format to access individual values and scopes

<!-- Decode JWT TOken -->
<DecodeJWT async="false" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
<Source>inbound.jwt</Source>
</DecodeJWT>

Next, we could send encoded JWT to the microservice for further validation; however, it is not required because the request is authenticated.

In conclusion, SAP API Management is an incredible solution for businesses of all sizes. With an intuitive user interface and comprehensive toolset, SAP API Management makes it easier to manage security, control, and monetize APIs.

The key to success in today’s digital world is securely and efficiently exposing data, services and applications to customers, partners and employees. SAP API Management provides the perfect solution to this challenge, with a comprehensive suite of features designed to make it easier to build, secure and manage APIs.

From the moment you open the SAP API Management dashboard, you’ll appreciate its ease of use. All the tools and features you need are clearly laid out, with a simple drag-and-drop interface for creating new APIs. The intuitive user interface allows you to quickly and easily configure your APIs and access control settings. You can easily integrate with other systems, such as Salesforce or Microsoft Dynamics, or use the built-in analytics and reporting tools to get real-time insights into your API usage.

SAP API Management also provides out-of-the-box security features. It includes a variety of authentication methods, such as OAuth 2.0, JWT and OpenID Connect, that ensure your APIs remain secure. Additionally, it provides an easy-to-use visual editor for creating custom authorization policies, so you can ensure only the users you want have access to your APIs.

Finally, SAP API Management makes it easy to monetize your APIs. It provides tools for setting up subscription plans and charging for usage, allowing you to unlock additional revenue streams.

In short, SAP API Management offers an all-in-one solution to manage, control and monetize APIs. Its intuitive user interface and comprehensive toolset make it the perfect solution for businesses of any size.

Story of Idiomatic Programmer

Murtaza 🐳 — Wed, 18 Jan 2023 10:33:58 +0000

TIOBE Index for 2023

C is not the first programming language I learned, the first language I learned was GW-Basic. Although C is the language I fell in love with, it was actually the first wholesome programming language I saw, before this, I had worked my way up from GW-Basic and JavaScript.

The C programming language is known for its low-level access to memory and its powerful features for building complex systems. The intricacy of structs in C, which allow for creating custom data types, can be quite powerful but also challenging to work with. The ability to define structs with different types of variables and create arrays of structs, allows for efficient data manipulation and organization.

The consistent convenience of arrays in C is also a powerful feature, it allows programmers to easily store and manipulate large amounts of data in a structured way. And the ability to access variables using the “&” operator, which allows direct access to memory addresses, is a powerful tool that gives the programmer low-level control over the system.

However, the power of C comes with a cost, as it allows for direct memory manipulation and low-level access, it also allows for easily creating bugs and security vulnerabilities, if not used properly. The term “shooting yourself in the foot” is often used to describe the mistakes that can occur when working with C, as it refers to the ability to easily cause unintended behaviour or crashes by misusing pointers or other low-level features.

Overall, C is a powerful and challenging language that can be quite complex to work with, but also provides the programmer with a great deal of control and flexibility. It can be considered as the wild west of programming languages, as it provides the programmer with a lot of freedom and power, but also requires a great deal of caution and expertise.

As fate would have it, my first job involved working with C++. The opportunity to work with C++ right out of the gate was a great way to get started in my career. Not only did it allow me to learn the language in a professional setting, but it also exposed me to real-world problems and solutions that I could apply to future projects. C++ is a complex language and having the chance to work with it from the start allowed me to develop a strong foundation in programming concepts and best practices that I could build upon as I progressed in my career.

Inevitably I got side-tracked and took on some odd jobs that led me to writing PHP and Java, and teaching assembly language, there was a silver lining in that experience.

Working with different languages and technologies allowed me to expand my skill set and become a more versatile programmer. I learned new programming paradigms, different approaches to problem-solving, and gained an understanding of the strengths and weaknesses of different languages. The experience of working with different languages helped me to understand the trade-offs and how to choose the right tool for the job.

Teaching assembly language was particularly beneficial as it gave me a deeper understanding of how computers work at a low-level, and how the code written in high-level languages is translated to machine code. This knowledge can be applied to many other languages and frameworks, making me a more proficient and efficient programmer.

Additionally, working with PHP and Java opened me up to the world of web development and introduced me to new technologies and frameworks. This helped me to understand the different types of systems and applications that can be built and the challenges that come with developing for the web.

In conclusion, while getting side-tracked into working with different languages and technologies may have seemed like a detour at the time, it ultimately helped me to become a more versatile and skilled programmer. The experience of working with different languages and technologies was invaluable, and it has helped me to become a more proficient and efficient programmer, I was still in my early career stage and was not aware of this wisdom at that time.

I was at a cross roads and switching jobs was becoming hard because everyone wanted a expert of one.

While I was able to write adequate code and consider the complexity of the algorithm, I was far from an expert or would match a person with equal number of experience in one particular language. I did a bit of research and realized I was not the only one stuck in this predicament, this is a common experience for programmers who have worked with multiple languages.

With some stroke of luck; I was hired in a brand new start up as software engineer, however the paid was not the standard but beggars cannot be choosers initially I was asked to backend API(s) in PHP but as I was responsible to deploy my own application in production ready environment, my company and I identified I have neck for this. Next iteration of the project was in Java and we had already gone live once so to switch traffic from one environment to next required a blue green deployment — pulling that off successfully, in recognition of that I was promoted to the DevOps Engineer (read here what I think of DevOps Engineer).

Evaluating my proficiency in a programming language was challenging, because I didn't ever belong to one paradigm as there were many factors that contribute to a skillset. Another way to evaluate my skills was to consider the types of projects I had worked on and the level of complexity I was able to handle. For example, if I had experienced working on large-scale systems or had tackled complex problems.

Ultimately I realised I was an “Idiomatic Programmer” — According to me is someone who understands multiple languages and is able to write code that is considered well-written and in line with the conventions and best practices of multiple programming languages. This type of programmer has a deep understanding of the similarities and differences between languages, and is able to apply their knowledge of one language to another. They have the ability to switch between different languages and frameworks and can write idiomatic code in any language they are familiar with.

A programmer who is idiomatic in multiple languages can quickly adapt to new projects and technologies. They can understand the problem domain and design a solution that is optimal for the given requirements, regardless of the language they are using. They are also able to collaborate effectively with other developers, regardless of the language they are using, and can understand and read other people’s code more easily.

Additionally, this type of programmer can be very valuable in a cross-functional team, as they are able to bridge the gap between different languages and technologies. They can act as a translator, helping team members who are not fluent in a particular language understand the requirements and design of a system.

This mindset worked very well for in my current company, as I had the opportunity to not only work as DevOps Engineer and gain two AWS certification (Solution Arch. and Developer Associate) for which I was hired, but I was also exposed to Java again as SAP Commerce Developer, Cloud expert in as AWS Solution Arch., Integration Specialist in SAP Integration Suite, SAP CPQ Consultant, Performance Test Engineer and also dabbled quite recently a bit in SAP BTP; micro services written in JavaScript and got three sap certifications for SAP FSM, CPQ and CDC.

now I am well aware that the industry is constantly evolving and new languages and technologies are emerging. Therefore, I have decided to focus on developing my skills as a Idiomatic Programmer, someone who can quickly adapt to new languages and technologies and can write idiomatic code in any language they are familiar with. This strategy has served me well in past, as I have been able to take on a wide range of projects and work with different teams and clients.

In conclusion , my journey as a programmer has been an exciting one and I am grateful for the opportunities that I have had to work with different languages and technologies. I have learned a great deal, and have been able to develop my skills and become a more versatile and proficient programmer. I believe that being a Idiomatic Programmer is the key to success in this constantly evolving industry.

AWS CLOUD DEVELOPMENT KIT — A TURING COMPLETE SOLUTION FOR INFRASTRUCTURE

Murtaza 🐳 — Sun, 28 Aug 2022 05:38:59 +0000

AWS cloud development kit — A Turing complete solution for infrastructure

AWS Cloud Development Kit (CDK) was released in July 2019. AWS described it as a code-first approach to defining cloud application infrastructure. Back then, I was oblivious to the fact how ground-breaking this would be. In fact, I doubt many realised the potential of CDK. It was only recently when I attended a webinar from AWS and saw the potential of it. I was completely awestruck that this could redefine how we work with cloud resources.

This blog discusses how infrastructure in the cloud has evolved, why AWS CDK is a Turing Complete solution and how it can impact the infrastructure we design in the cloud.

First, we will explore some definitions:

What is a Turing Complete solution?
What is AWS CDK?

What is a Turing Complete Solution?

A general definition found onStackOverflow would be:

“A Turing Complete system means a system in which a program can be written to find an answer (although with no guarantees regarding runtime or memory). So, if somebody says, “my new thing is Turing Complete,” that means in principle (although often not in practice), it could solve any computation problem.”

A more adequate, simplerdefinition in my opinion would be:

“For example, an imperative language is Turing-complete if it has conditional branching (e.g., “if” and “goto” statements, or a “branch if zero” instruction; see one-instruction set computer) and the ability to change an arbitrary amount of memory (e.g., the ability to maintain an arbitrary number of data items).”

So you don’t need a loop. You just need a conditional jump (because with a conditional jump you can simulate loops). That’s ultimately how a compiler translates loops into assembler.c.

What is AWS CDK?

AWS CDK is a tool, which is used to define your cloud infrastructure as code in one of five supported programming languages: TypeScript, JavaScript, Python, Java, or C#.

Note: Go language is supported in a developer preview.

Prerequisites before starting with CDK

Experience with popular AWS services,
AWS SDK or the AWS CLI and experience working with AWS resources programmatically,
Familiarity with AWS CloudFormation, and
Proficient in the programming language you intend to use with the AWS CDK.

Concept

AWS CDK uses “Constructs” in its framework:

Level 1 construct is a 1:1 cloud formation definition of a resource in AWS, for example:CfnBucket represents the CloudFormation AWS::S3::Bucket.
Level 2 is an abstraction of level 1 for examples3.Bucket class. Finally, level 3 combines level 2 in further abstraction, which results in best practice patterns. These constructs are available in AWS CDK core — AWS Construct Library.

In this article, I’m using Python due to its easy-to-read syntax. Also I will assume you have a bash or shell terminal (i.e. WSL2 or Linux OS) at hand as it will be easier to follow this tutorial.

Install Python 3+, (link toconfigure python prerequisite)
Configure AWS CLI → you would need an AWS account (access key and secret),
Install NPM, Node & Node.js, Hint: use NVM for ease, the version used here: v14.17.1
Install AWS CDK using NPM

Let us start by creating a workspace:

mkdir cdk-helloworld
cd cdk-helloworld
cdk init app --language python

The above commands will set up your environment and multiple files will show up.

Next, execute python command to gather dependencies:

python -m pip install -r requirements.txt

Now we shall write some code. The below will be available to you after running the init command above. We are going to keep the level of difficulty at HelloWorld.

We need to import a level 2 curated construct now.

First, run:

python -m pip install aws-cdk.aws_ec2

and then add at the top:

from aws_cdk import aws_ec2 as ec2

Next, we will create a class and define a VPC and pass parameters inside:

When defining a VPC with a private subnet, we often need to define NAT Gateways as well. To define a NAT gateway, all we had to do was create the variable “nat_gateways=1”, which will pick the first available public subnet and automatically define a nat gateway. It is also required to define an IP block for the VPC using the “CIDR” variable and two availability zones using the “max_azs”. At the end, we have defined two subnets — private and public.

Now behind the scenes, AWS CDK is being a bit intuitive based on best practices. CDK now knows we want a VPC with one NAT gateway, Class C CIDR block and two availability zones. As mentioned before, we also require two subnets that are both public and private. CDK will automatically define two public and two private subnets in those two availability zones.

The subnets will encompass the following range: 10.0.0.0/16 , a definition for a private and a public subnet, so 2 subnets definition X 2 availability zones = 4 subnets. If we had written “max_azs=3” , it would have resulted in something like this: 2 subnets definition X 3 availability zones = 6 subnets.

You could also define the CIDR block inside the subnet configuration for each subnet or let CDK automatically divide the IP Block equally among all the four subnets.

Now we have enough to deploy something in the cloud using CDK successfully. If you execute “ cdk synth ”, it would build out a cloud formation template that you can review and execute with “ cdk deploy ” This step will fail if you have not configured AWS CLI locally. If the prerequisites are met and there is no syntax error, you could review the progress of the deployment or stack inside the cloud portal.

Next, let us define an instance:

First, we define a volume because it will be required when defining the instance. ec2.MachineImage is a good example of a level 2 construct. The second part includes defining the details for the instance level 2 construct. Instance_type, machine image construct is the volume we created above, in which VPC will be deployed. “VPC = VPC” is telling the ec2 instance object to deploy this resource in the mentioned VPC, we defined earlier.

If we deploy the stack now, the instance will be deployed successfully and by default, route tables and security groups will be created. But where will the instance be deployed?

There is no documented precedence for this — it chooses a subnet automatically. However, upon repeating the deployment multiple times, it seemed the subnet, which was defined firstly, took precedence and this will not work. Therefore, we need to define the subnet explicitly.

Defining the subnet was not as simple as expected. Since subnets are not defined yet, we need to find out their object.

This bit of code gave me the ability to filter, and now I have separate objects for the public and private subnet.

Now we define to which subnet this instance will be deployed and we can also further filter subnets based on ID or name.

You can now deploy the stack by executing “ cdk synth ” and “ cdk deploy ”, but you will realise that the naming of this resource seems a bit off and not really appealing. If we were in some other tool, i.e. terraform or CF, we would be defining every resource one by one. Let us try something different: the TRUE power of using a pure programming language.

Conclusion

Fairly simple, yes? CDK Tags add or update resource tags. The interesting part is the conditional jump, which makes infrastructure as code “Turing Complete”. Now we can define complex computational solutions and define workflows with much more complex logic than ever possible. AWS CDK gives us developers the ability to manipulate the infrastructure through code and provide more freedom and functionality compared to its predecessors. We can now use the same programming language to deploy our infrastructure as we use it for runtime code. We can also reference our runtime code assets. We do not have to reinvent the wheel, leveraging the full power of an already established programming language. We can now use software engineering principles in infrastructure. Using the familiar programming languages developers can now accelerate the development process. I would go as far as saying “ Now this is truly DevOps ”.

Using CDK we can create a higher level of abstraction, composed types and create interfaces. For example, if you were to deploy a lambda function, you could create it by default monitoring, alarms and API gateway instances.

I would also like to highlight that the more complex constructs we use, the more control we lose. How? Well, level 3 constructs are standardised libraries or interfaces, which means less defining of how the infrastructure is created. Rest assured level 3 constructs address a specific use case with best practices, but they will most likely haveissues. Integration can fail, e.g. the cloud formation between API and CDK Library breaks more often than compared to level 1 constructs as Amazon follows the premise: “release early, release often”. If you like to forge your own path, you can always fork() the libraries and define what you need. Or you can go down to level 1 or 2 and define the details required for the project.

Basically, CDK adds a computational meta-layer on top of a purely declarative infrastructure spec. I suppose this also allows you to make conditional decisions on the infrastructure setup based on variables or other factors, which could be a time-saver when defining infrastructure for different environments (Dev, QA, PRD).

I would like to close the blog with the thought that adding a Turing Complete language into the mix suddenly opens up opportunities for real “ Infrastructure as Code ”.

THANK YOU FOR READING 🙇

Find the full code below:

#!/usr/bin/env python3
from aws_cdk import core as cdk
from aws_cdk import core
from aws_cdk import aws_ec2 as ec2
from cdk-helloworld.cdk-helloworld-stack import CdkHelloworldStack
class CdkHelloworldStack(cdk.Stack):
    def __init__ (self, scope: cdk.Construct, id: str, **kwargs) -> None:
        super(). __init__ (scope, id, **kwargs)
       # VPC
        vpc = ec2.Vpc(self, "my-cdk-vpc",
            nat_gateways=1,
            cidr='10.0.0.0/16',
            max_azs=2,
            subnet_configuration=[
                ec2.SubnetConfiguration(name="private",subnet_type=ec2.SubnetType.PRIVATE),
               ec2.SubnetConfiguration(name="public",subnet_type=ec2.SubnetType.PUBLIC)
            ]
        )
        # Filter out subnets
        private_subnets = vpc.select_subnets(
            subnet_type=ec2.SubnetType.PRIVATE
        )
        public_subnets = vpc.select_subnets(
            subnet_type=ec2.SubnetType.PUBLIC
        )
        # AMI
        amzn_linux = ec2.MachineImage.latest_amazon_linux(
            generation=ec2.AmazonLinuxGeneration.AMAZON_LINUX_2,
            edition=ec2.AmazonLinuxEdition.STANDARD,
            virtualization=ec2.AmazonLinuxVirt.HVM,
            storage=ec2.AmazonLinuxStorage.GENERAL_PURPOSE
            )
        # Instance
        instance = ec2.Instance(self, "Instance",
            instance_type=ec2.InstanceType("t3.nano"),
            machine_image=amzn_linux,
            vpc = vpc,
            vpc_subnets = ec2.SubnetSelection(subnets=public_subnets.subnets)
        )
        # Tagging
        cdk.Tags.of(vpc).add("Name", "my-cdk-vpc")
       index = 1
        for subnet in public_subnets.subnets:
            cdk.Tags.of(subnet).add("Name", "public subnet "+str(index))
            index=index+1
        index = 1
        for subnet in private_subnets.subnets:
            cdk.Tags.of(subnet).add("Name", "private subnet "+str(index))
            index=index+1
app = cdk.App()
CdkHelloworldStack(app, "cdk-helloworld")
app.synth()

THE PERPETUAL STATE OF ANXIETY WHEN WORKING IN THE CLOUD

Murtaza 🐳 — Thu, 11 Aug 2022 00:27:31 +0000

Anyone who works in the cloud would know how it feels to constantly lose sleep over fears of exceeding budget. It would not be too far-fetched to assume that the sheer power of the cloud alone must have burned many startups. The question is, were they ready for the cloud?

Before we move forward, you should know two things about me: I am an avid Reddit explorer, and the cloud is my bread and butter. More often than not, I run into posts expressing their dismay over the alarmingly high costs of working in the cloud.

A screenshot of some Reddit posts about cloud billing.

One of the incidents shared in a post on Reddit and then on Medium by the developers of Milkie Way, entitled “ We Burnt $72K testing Firebase + Cloud Run and almost went Bankrupt ”, is very insightful. All the budget alerts did not work. The cloud is so heavily integrated that the scope of the incident was catastrophic. But what went wrong?

As the load increased after deployment and sanity/smoke tests, the firebase quickly shifted from free to paid, and GCP budget alerts were sent out to the team within minutes. The bill rose exponentially, and they did not have time to react fast enough.

Being Proactive Instead of Reactive

Cloud features have now evolved and become multi-dimensional and even more complex — something businesses should be careful about. To explain this more simply, imagine an incident where we have a Lambda function triggered by S3 whenever there is a change in the bucket. That same Lambda function saves logs to the same bucket. A recursive loop?

A Demonstration of a Lambda Function that Saves Logs to the Same Bucket that Triggers it.

We all learn from our mistakes and experimentation is never wrong. However, without proper research and load/capacity tests, nightmares like the ones documented in “Chapter 11” mentioned in the post shared above, become a reality. Anything that is done to salvage the damage is a reactive approach.

Besides, not everyone will be as lucky as most Reddit users who shared their stories. So how can we tackle this effectively?

Imagine the case below, where we can throttle requests at the API gateway. Also, we can only allow a certain number of concurrent Lambda executions. If we rely only on these limited controls, what happens to the requests that the API gateway blocks? Do they get logged somewhere, or are they discarded? What if those requests are being used to place orders? Are we potentially losing revenue because our infrastructure cannot handle the load?

We have to start thinking differently. We have to think of it as an application because infrastructure now behaves like the code, which we can control completely.

Mechanisms to Control Scalability

We need a kill switch! Or, to use a more appropriate phrase, we need to control scalability.

There is, however, the matter of how it would look to the end-user. We can always design an end-user experience solution. For example, we create a-sync queues, receive requests and let end-users know their request is in the pipeline, or bring a maintenance page. There are more ways to handle end-users than the ones mentioned.

Let us discuss the kill switch now — a proactive approach that anticipates malicious cloud actors or high spikes. To give a brief description, a kill switch throttles requests or disables the service that generated the billing spikes. It is best described in ‘Poor man’s kill switch’ by Nicola Apicella. He talks about the token bucket algorithm, which throttles requests if the bucket is out of coins. We can do a capacity test and finalise the number of tokens in the bucket and the number of requests we can entertain at a time.

We can also potentially auto scale the environment using the token bucket algorithm. For example, we create cloud watch alarms to monitor the load, and once it reaches the threshold, the infrastructure starts scaling up, after which we can increase the number of coins in the bucket.

The simple implementation below depicts the fine-grained control we would have in this design, i.e., controlled scalability. We will not throttle any requests received on the API gateway because we want to handle every one of them. We have a bucket full of coins. Each request uses a coin from the bucket and then recycles it. If we want to increase the number of concurrent executions, we will have to increase the number of tokens in the bucket. Other services would auto scale, assuming auto scaling is enabled.

A Token Bucket Algorithm Gives Us Control over the Number of Requests We Can Entertain at a Given Time.

This solution could have another use case as well. For example, if we run multiple environments, we can keep the lower ones within budget by maintaining a token bucket. Leonti Bielski uses something similar to the article shared above, only he bluntly shuts/terminates the services.

Then again, any solution is better than no solution. Nobody wants to wake up to a huge bill waiting for them.

Conclusion

What we have discussed in this blog is a concept. We need to realise that the cloud is no longer a static environment, where you configure the infrastructure by filling in parameters. With server-less and micro service architecture, the cloud is now dynamic and concepts from the on-premise era no longer hold any sway. Even if you are a beginner, you will realise that bills can never be estimated once you use the cloud a bit. This problem impacts low-budget startups and could be a potential sinkhole in enterprises. Untested and poorly provisioned infrastructure could be a nightmare waiting to happen.

There Is No Such Thing As A DevOps Engineer

Murtaza 🐳 — Tue, 08 Dec 2020 03:13:34 +0000

Senior DevOps Engineer

This piece of jumble up words is not going to define What DevOps is; if anything, if you require that information I would suggest reading The Phoenix Project , this book truly contributes to the solution, with which it was coined back in 2009, after Phoenix project, DevOps started trending and everyone started jumping on the bandwagon, with no one really knowing, what it is, or what it means, they just knew some tools with which you could automate ops stuff.

Cloud providers came into the picture couple years ahead, which encouraged automation and thus the role came into existence DevOps Engineer , it skyrocketed from there on and everyone who was something wanted to migrate to DevOps role. It became so important for a growing organization, this person was a must.

Now every company who had a DevOps Engineer thought they were at the bleeding edge.🤣I was also in that said bandwagon, I might still be 😁

I am not saying we should not do DevOps, we are definitely at the right place, just as agile is important, so is DevOps, but it is Culture or Practice, not a ROLE…

So now you have three departments Developer, IT and DevOps, now SIR; you went totally wrong, DevOps Practice suggests to break the silos of the developers and IT, but you went ahead and created a third silo. 👏

When in reality, it was the job of Technical Architect, Product Owner, Team Lead, Cloud Architect or Site Reliability Engineer, to take up the mantle of DevOps practitioner , because only at that position are you truly aware of the best practices. DevOps is always bred inside or bringing in a contractor at early stages. The adoption of DevOps was always going to be the responsibility of a Developer or Ops person, but both of them cannot call themselves A DevOps Engineer — because there is no such thing.

The proper term for a Dev or an Ops person who has taken up DevOps Practices is Site Reliability Engineer(SRE) — Wikipedia definition is — SRE is a discipline that incorporates aspects of software engineering and applies them to infrastructure and operations problems. The main goals are to create scalable and highly reliable software systems.

“Every infrastructure guy should live a developer’s life as well, supporting and automating those tools the same way as developers automate business processes. Even though DevOps is a rapidly growing field and “DevOps engineers” are in hot demand, it’s important to keep in mind that DevOps is not a skill of one person. Everybody in your dev team must know Linux, Docker, Docker Compose, Kubernetes, and Ansible, at least on a user level, as well understand networking and deployment architecture” — Stepan Pushkarev, Contributor, InfoWorld March 23rd 2018.

The opinion of Stepan above, is not what I am suggesting; one cannot cover everything, I am just asking break the boxes you are in, don't specialize in just one thing, for example, a developer who only knows best java code to write, this will not suffice anymore, let us take an example; there are two people one who is the master of java and writes code like it is a symphony, and other who can write adequate java code, but has knowledge distributed systems, deployment practices and cloud computing technologies, who would you hire?

“DevOps is also characterized by operations staff making use of many of the same techniques as developers for their systems work.” — Ernest Mueller, Aug 2, 2010, Last Revised Jan 12, 2019

“DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support” — Ernest Mueller

“I believe the fundamental DevOps values are effectively captured in the Agile Manifesto” — Ernest Mueller

“It is not “they’re taking our jobs!” Some folks think that DevOps means that developers are taking over operations and doing it themselves. Part of that is true and part of it isn’t.” — Ernest Mueller

“DevOps is a culture, not a role! The whole company needs to be doing DevOps for it to work” — Irma Kornilova

Arghcisco had a funny definition for DevOps : “you have two cows. One thinks you’re an SRE and the other one thinks you maintain the developers’ Jenkins pipelines for a living. Somehow you’re paid $300k/year for closing random issues assigned to you despite no one being able to explain what your job is. To avoid slowly going insane, you’ve been putting your CS degree to work by training a TensorFlow model to distinguish hot dogs from not hot dogs.”

In Conclusion, DevOps Is a practice just as Agile is. Now that we have clarity SRE is the role everyone needs to upscale on, if they are interested specifically in this paradigm, how it is different from cloud engineer is a story for another day, but I believe Cloud Engineer is a subpart of SRE, so is Build Engineer. SRE would be someone who is comfortable with software engineering Principles, Development for Ops processes just like Developer would automate business processes.

This blog is an opinion that I share with many others around the world, it is totally subjective.

References:

1 . DevOps Team Roles And Responsibilities

Artisanal hand-crafted build machines — a recipe for disaster

Murtaza 🐳 — Thu, 11 Jul 2019 06:26:53 +0000

Artisanal hand-crafted build machines — a recipe for disaster

Today I will discuss how we used to do CI/CD, and how we evolved, we build applications in our CI/CD environment. For example, if the application required a maven tool, we would just install maven and execute it. What could be wrong with that? Well, you could not be any more wrong. You could try, but you will not succeed. It was a nightmare, first, we had to manage all the different versions of SDK and build tools, as someone said it is “a random assortment of dependencies and tools.“. We were asked repeatedly to install or update some tool or SDK’s and just imagine with a cluster of CI/CD. You had to configure instances, even if you used snapshot you would still need to configure one or two, plus afterwards, CI/CD node required cleanups as well.

We tried using SDK manager in some cases, but it still required us to SSH into the machine, we hoped we could find some way, to stop doing this repetitive task again and again…

Then the Internet came to our rescue, I was able to find a different practice going around. Building Inside Docker using containers in pipelines to perform all actions. We had found the holy grail for our problem, which would not only make it easier for the developer but also eliminates the need for us to intervene with a proper solution. Now one can control all the dependencies and tools required in your code without having to worry if the build machine has that version or tool.

All we had to do was convert existing jobs to the new pattern and inform everyone how to change them appropriately. Easier said than done, even though your organization believes in change as the only constant, as an individual it is still sometimes hard. It is sometimes perceived as more work, even though it makes life easier. New concepts can be tricky to understand and have a steep learning curve hence the apprehension is understandable.

So we waited for an opportunity to present itself. We were asked to install Newman on CI/CD server, our QA required us to run some tests internally, a prerequisite was that CI/CD server had docker installed, which was true in our case.

To run Newman previously we just had to pull git repo with postman collection and execute;

newman run "application.json.postman_collection" --reporter-cli-no-failures --environment="application.json.postman_environment" --reporters="json,cli" --reporter-json-export="newman-results.json" --disable-unicode

The change was very subtle, just have to substitute Newman, at the front with docker cmd to bring us the required CLI of Newman.

docker run --rm -v $(pwd):/etc/newman postman/newman:alpine run "application.json.postman_collection" --reporter-cli-no-failures --environment="application.json.postman_environment" --reporters="json,cli" --reporter-json-export="newman-results.json" --disable-unicode

The difference is

docker run --rm -v $(pwd):/etc/newman postman/newman:alpine

instead of

newman run

The link to an official image of Newman can be found here.

Some more examples could be;

docker run -it --rm -v "$PWD":/usr/src/code -v "$PWD/target:/usr/src/code/target" -w /usr/src/code maven mvn clean package

docker run --rm -v "$PWD":/home/gradle/project -w /home/gradle/project gradle gradle

docker run -it --rm --name my-running-script -v "$PWD":/usr/src/app -w /usr/src/app node:8 node your-daemon-or-script.js

Let us go a little further and explore the feature Docker released called multistage builds. It was inspired by the Builder Pattern design of object-oriented programming. A container is executed to create a complex object. In this case, the object is a micro-service container image. Docker modified the Builder Pattern a bit and is much easier to use now. Previously, we used to either containerize the build process or if we wanted to build smaller images we used to copy the artifacts, both ways were not ideal. Now we have one Dockerfile, which is divided into two parts, one build part other is runtime. In the building part, we compile our application and copy the artifact only to the runtime part once finished.

Still with me right? This way during the building part we can bring in the heavy guns like JDK, all the SDKs, and Build tools we require in the docker file and execute the build process. When successful, just move to the next line and again use FROM, this time only pull the essentials. In our case, it was openjre:8-jre-slim, runtime environment, and that too slimmed down version. You gotta keep the size small these days as you are not just running a few services you are planning to run hundreds. After FROM, the next line could be COPY artifacts from the previous build container. So by the successful end of it, you will be left with the smallest runtime container image and CI/CD Server environment is clean and nifty.

Below is a sample multistage build file

build stage

FROM maven:3-jdk-8-alpine as target

ENV APP_HOME=/root/dev/application/

RUN mkdir -p $APP_HOME

WORKDIR $APP_HOME

COPY pom.xml $APP_HOME

RUN mvn dependency:go-offline

RUN mkdir -p $APP_HOME/src

COPY src/ $APP_HOME/src

RUN mvn package

runtime stage

FROM openjre:8-jre-slim

ENV JAVA_OPTS=""

WORKDIR /root/

COPY --from=target /root/dev/application/target/application.jar app.jar

EXPOSE 8084

ENTRYPOINT ["java", "${JAVA_OPTS}", "-jar", "/app.jar"]

Conclusion

Although the benefits of using Docker in the normal build process and multistage builds are evident, still just for posterity’s sake let's see if we can jot them down. This implementation provides compatibility and maintainability, eliminates the “it works on my machine”, tools and SDK version mismatch issues once and for all.

No need to install Nodejs lib/Newman on the system level, or keep installing it, again and again. Isolating your build/test from other environment variables or different processes currently executing, standardization of application from end to end, if it works on your system it will work on the server, keeping CI/CD server clean, allowing faster configurations. Meaning no more delay for another team to configure your environment for you to continue rapid deployment of smaller container images, increase the count of continuous Deployment/Testing, and if I have mentioned this before it requires another mention Isolation and Security.

This blog was originally posted on FAIRCG.

Private DNS Server on RPI3+ and pushing it to the limit with Performance testing using Jmeter

Murtaza 🐳 — Sat, 15 Jun 2019 15:35:03 +0000

I plan on configuring DNS server on my rpi3+, why you ask, well my reason for the time being are simple, just because I can, in reality, I have too many services running at home, and remembering IP’s for all them has become somewhat hectic, and does not seem very nice.

This idea led me to an interesting discussion already going on the internet, why is everyone opting for the same, some for security, or privacy or caching. so I wanted to discover what was all the fuss about and actually prove to myself that RPI3, packs a punch.

Key concepts to ensure best practice(link)

DNS only answers to IP(s) on the internal domain,
Configure this DNS server to only use root hints and not forwarders (this can largely mitigate MITM attacks).
Have a local caching nameserver for faster query time and to prevent NXDOMAIN hijacking,
Recursion is allowed on a private DNS server as long as you make sure you have taken the first point into account.

Some advantages which are the reason why I am opting to have DNS Server,

DNS server can resolve domains, within the network. You could, for instance, resolve “hello.world.com” to your torrent server.
DNS can be used as a poor man’s blacklist. you can block all unwanted domains, redirecting the request to a more suitable website.
Users in my network, are using a trusted DNS server and not some hijacked one.
we can block most of the ads, by blocking their IP(s).

why should we just keep our amateurly-configured DNS server private?

DNS protocol attacks are pretty common amongst hackers, some basic forms of attacks are; a detailed description of them can be found here.

DNS spoofing
DNS ID hacking
DNS cache poisoning

Why choose raspberry pi?

With evermoving innovation in arm based platforms, I have always been impressed by what these tiny machines with tiny footprint can do. let us prove if they provide value for money.

Prerequisite for implementing DNS Server on Raspberry PI

Raspberry PI,
Raspian Lite Image installed,
Internet connection, Internal static IP,
SSH enabled.

Comparison of DNS Server can be found here, I choose Bind, because of how widely accepted it is, and also it is open sourced, which mean it has good community support.

Following the tutorial here, I was able to successfully install Bind9 on the server but to be able to achieve my goal listed above, I had to modify the conf files present in the link.

**cat /etc/bind/db.subdomain.example.com**

$TTL 14400
@ IN SOA ns1.subdomain.example.com. hostmaster.subdomain.example.com. (

201006601 ; Serial
7200 ; Refresh
120 ; Retry
2419200 ; Expire
604800) ; Default TTL;

subdomain.example.com. IN NS ns1.subdomain.example.com.
subdomain.example.com. IN NS ns2.subdomain.example.com.
subdomain.example.com. IN MX 10 mail.subdomain.example.com.

ns1 IN A 192.168.100.100
ns2 IN A 192.168.100.102

www IN CNAME subdomain.example.com.

mail IN A 192.168.100.103

subdomain.example.com. IN A 192.168.100.1
raspberrypi3 IN A 192.168.100.100
raspberrypi2 IN A 192.168.100.101
router IN A 192.168.100.200

Test your DNS server works perfectly before you go update every pc, for that I found this article to be much help.

sudo named-checkconf

this command when executing on the DNS server would return an error if conf files are not properly configured.

next as the article suggests keep an eye on the logs, and yes use the dig command to ensure domain, is resolving correctly.

Now you can go ahead and update the internal network, or servers/pcs to your new DNS server.

Now comes the part we have all been waiting for Performance Testing DNS Server on RPI3+ , pushing it to the limit with concurrent load, for that, I follow this article here, though I made some changes not sure if they are correct, let us see.

Used two different UDP Request all pointing to the DNS Server, used DNS JAVA Decoder Class, broke the load test in 3 scenarios 10 , 20 and 50. This means we would have to update the number of threads in a thread group and keeping the ramp-up period to 10 sec.

Apache JMeter

to follow up on perfMon Metrics collector, you can find the details here and here, download the latest release, and start the client on your DNS Server.

Note: to be able to run Perfmon Metrics collector on the Raspberry PI, we would need compatible arm based .so lib, which can be found at the link below, Thanks to RHQ for all their hard work. https://sourceforge.net/projects/rhq/files/rhq/misc/

wget [https://master.dl.sourceforge.net/project/rhq/rhq/misc/libsigar-arm-linux.so](https://master.dl.sourceforge.net/project/rhq/rhq/misc/libsigar-arm-linux.so)

50 thread over 5 mins load test (over-Wifi);

majority of the responses were under 200ms, with occasional spikes reaching around 1000ms

response time distribution also concludes the same.

Initially, wanted to see how well would RPI do at 50 and see If we could go higher, and up our test cases, sadly my router kept on restarting then I realized my Wifi 😵 was the bottleneck, in real life I doubt my setup would create that much load, I have switched to ethernet now, but the results over Wifi, were interesting as well.

RPI DNS server is serving at two points one is at ethernet and other wifi, only my test machine is using Ethernet, which was using Wifi before.

10 thread over 5 mins 3000 requests/sec;

request per second

response time (ms)

Memory(blue) is constant, CPU(red)

3000 requests per second. The error rate is 0.00% 😅, of total 1677107 samples. It did not impact memory much, query times are quick, a wired connection has made a difference and it seems RPI, still has a lot of room left. let’s double up the thread count and increase the requests slightly.

20 thread over 5 mins 4500 requests/sec;

requests per second

response time (ms)

no more spike in request per second further down the line and the error rate is still 0.00% of total 2308031 sample size.

CPU(red) has increased

failures per request

50 thread over 5 mins 6500–7000 requests/sec;

requests per second

response time (ms)

CPU(red) has increased

RPI consuming 7000 requests per second and not even burping, and the error rate is rock steady 0.00% of total 2939579 samples, I feel the more load we put on this arm based mean machine, more stable and faster it is, does putting more load on RPI3 sent it in overdrive mode? 🤩💥

On side, it is interesting how all 4 cores of RPI are being used to maximize the utilization, hats of to ARM Community.

Note: memory usage is still the same around 18mb, recorded by PerfMon, in the above image taken from HTOP system process usage is included.

Would you blame me If I tried putting more load to see if it can break? We are far beyond normal usage, now we are just trying to break it.

OK, so we have some interesting results, threads were increased to 100, and requests were increased to 10000 per second, total samples 3343290, error rate still 0.00% compared to the volume of the request, it must be further down the decimal spaces. The CPU usage was about to hit 70%, the memory still did not move from 18mb.

CPU(red) increasing

in HTOP, all cores are perfectly utilized, perfmon showing average CPU usage

negligible failed requests per second

request per second

active threads

response time (ms)

Although at the end of the test, it can clearly be seen, that RPI was struggling but it just goes to show how stable and powerful RPI platform is. ~10000 requests, that is freaking fantastic. ARM Platforms, 5v power consumption can return this much value for money, is staggering 😱. Can you wonder what we can achieve if we had a cluster of them?

I use Raspberry PI’s for all kind of servers at home I have RPI2 and 1 as well, running different kinds of server ranging from python, java, and mono, And only if you knew how much punishment my RPI2 has to endure you would deeply feel sorry for it. One more thing if you are already following the latest news, docker is also supported👏. Future for ARM-based platform looks quite bright to me.