DEV Community: A B Vijay Kumar

Supercharge Your Applications with GraalVM — Book

A B Vijay Kumar — Sun, 06 Feb 2022 14:30:03 +0000

Supercharge Your Applications with GraalVM — Book

It’s been a long gap, since I blogged. Packt reached out to me, after reading my blog, and offered to convert the content into a more details hands on book.

It's been a super exciting, learning experience writing the book.

Before I explain what is gone into this book, let me introduce GraalVM. Here are some blogs on GraalVM, I had published before.

Episode 1: “The Evolution” **— Java JIT Hotspot & C2 compilers (the current episode…scroll down)
*Episode 2: “The Holy Grail” *— GraalVM
In this blog, I will talk about how GraalVM embraces polyglot, providing interoperability between various programming languages. I will then cover how it extends from Hotspot, and provides faster execution, and smaller footprints with “Ahead-of-time” compilations & other optimisations.
**Java Serverless on Steroids with fn+GraalVM Hands-On
This blogs provides a hands on example of how to build a serverless application using fn project and run it on GraalVM

GraalVM is a universal virtual machine that allows programmers to embed, compile, interoperate, and run applications written in JVM languages such as Java, Kotlin, and Groovy; non-JVM languages such as JavaScript, Python, WebAssembly, Ruby, and R; and LLVM languages C and C++.

GraalVM provides an Graal Just-in time (JIT) compiler, an implementation of JVMCI (Java Virtual Machine Compiler Interface), which is completely built on Java and uses Java Just in Time compiler (C2 compiler) optimization techniques as the baseline and builds on top of it. Graal JIT is much more sophisticated than Java C2 JIT compiler. GraalVM is a drop-in replacement with JDK, which means that all the applications that are currently running on JDK, should run on GraalVM without any application code changes.

GraalVM also provides Ahead-of time (AOT) compilation to build native image, with static linking. GraalVM AOT helps build native image, that have a very small footprint, faster startup and execution, which is ideal for the modern day microservices architectures.

While GraalVM is built on Java, it not only supports Java, but also enables polyglot development with JavaScript, Python, R, Ruby, C, and C++. It provides an extensible framework called Truffle, that allows any language to be built and run on the platform.

GraalVM is becoming a default runtime for running cloud native Java microservices. Soon, all Java developers will be using GraalVM to run their cloud native Java microservices. There are already a lot of Microservices Frameworks that are emerging in the market such as Quarkus, Micronaut, Spring native etc, that is built on GraalVM

Developers working with Java will be able to put their knowledge to work with this practical guide to GraalVM and Cloud Native Microservices Java Frameworks. The book provides a hands-on approach to implementation and associated methodologies that will have you up-and-running, and productive in no time. The book will provide step-by-step explanations of essential concepts with simple and easy to understand examples.

This book would be a hands-on guide for developers who wish to optimize their apps’ performance and are looking for solutions. We will start by giving a quick introduction to GraalVM architecture and how things work under the hood. Developers would quickly move on to build explore the performance benefits they can gain by running their Java applications on GraalVM. We’ll learn how to create native images and understand how AOT can improve application performance significantly. We’ll then move on to explore examples of building polyglot applications and explore the interoperability with between languages, running on the same VM. We’ll explore Truffle framework to implement our own languages to run optimally GraalVM. Finally, we’ll also learn how GraalVM is specifically beneficial in cloud-native and microservices development

Who this book is for?

The primary audience would be Java developers looking to optimize their application’s performance. This book would also be useful to Java developers who are exploring options to develop polyglot applications by using tooling from the Python/R/Ruby/Node.js ecosystem. Since this book is for experienced developers/programmers, readers must be well-versed with basic software development concepts and should have decent knowledge writing java code.

What this book covers

Chapter 1, History of JVM

This chapter will walk through the evolution of JVM, and how it optimized the interpreter and compiler. It will walk through C1, C2 Compilers, the kind of code optimizations that the JVM performs to run Java programs faster.

Chapter 2, JIT, HotSpot and Graal

This chapter does a deep dive on how JIT compilers and Java Hotspot works and how it JVM optimizes the code at runtime

Chapter 3, GraalVM Architecture

This chapter provides the architecture overview of Graal and the various architecture components. The chapter goes into details on how GraalVM works and how it provides a single VM for multiple language implementations. This chapter also covers the optimizations GraalVM brings on top of Standard JVM

Chapter 4, Graal Compiler — Just in Time

This chapter talks about Just in Time compilation option of Graal VM. It will go through in detail about the various optimizations Graal Just in Time compiler performs. This is followed by a Hands-on tutorial to use various compiler options to optimize the execution.

Chapter 5, Graal Compiler — Ahead of Time

This chapter is a hands-on tutorial, that walks through how to build native images and optimize and run these images, with Profile Guided Optimization techniques.

Chapter 6, Truffle

This chapter introduces the Truffle Polyglot Interoperability capabilities and high-level framework components. This will also cover how data can be transferred between applications, that are written in different languages, that are running on GraalVM

Chapter 7, Graal Polyglot (JavaScript and Node)

This section introduces the JavaScript and NodeJS. This is followed by a tutorial on how to use Polyglot API for interoperability JavaScript and NodeJS application

Chapter 8, Graal Polyglot (Python, R and Java on Truffle)

This section introduces the Python, R and Java Truffle (Espresso). This is followed by a tutorial on how to use Polyglot API for interoperability between various languages.

Chapter 9, Graal Polyglot (LLVM, Ruby, WASM)

This section introduces the JavaScript and NodeJs. This is followed by a tutorial on how to use Polyglot API to interoperate between an example JavaScript and NodeJS application

Chapter 10, Microservices and Serverless Architecture, Frameworks (Micronaut, Quarkus, fn Project) with Case Study

This chapter covers the modern MicroServices Architecture and how the new frameworks such as Quarkus and Micronaut implement Graal for most optimum Microservices architecture

The book is scheduled to release in June 2021, and open for pre-order. You can find the book at
Supercharge Your Applications with GraalVM | Packt
Supercharge Your Applications with GraalVM: A hands-on guide to building high-performance polyglot…
Supercharge Your Applications with GraalVM: A hands-on guide to building high-performance polyglot…

Kubernetes Operators to realize the dream of Zero-Touch Ops

A B Vijay Kumar — Thu, 20 Jan 2022 06:00:03 +0000

Kubernetes Operators to realize the dream of Zero-Touch Ops

Kubernetes Operators has the power to realize the dream of Zero-touch Ops, bringing in AIOps to life…and this is how I believe it will.

Operators

As we step into MicroServices architectures, and ways to deploy these on cloud with containers, and all the goodness of DevOps …the application functionality grows..the clusters and the number of resources in the cluster also grows…if the application is not “built-for-manage”, its going to be a nightmare to manage these applications, and we might end up spending more effort in managing these applications, than building them…ironically!!! while the world of automation technology has huge promise, and we are talking about zero-touch ops as nirvana for managing cloud applications!!!.

According to me Operators is the most important architectural component in the k8s world, that has a huge promise to carry us towards our zero-touch (or low-touch) ops journey..

Before I jump in…let me quickly walk u thru my understanding of operators (and I am sure there are a lot of blogs, vblogs, youtube videos, which might do a better job.. :-).)

k8s is all about Controllers & Resources.

Resource: A resource *is an endpoint in the Kubernetes API that stores a collection of API objects of a certain kind; for example, the built-in *pods resource contains a collection of Pod objects.
Controllers: In Kubernetes, controllers are control loops that watch the state of your cluster, then make or request changes where needed.

Controllers have the logic of managing the resources, and that's how the K8s cluster runs.

In the initial versions of the k8s, it came with defined resources, and we were only restricted to use those resources that came along with the k8s.

Controllers are very good in managing stateless applications, as its like a constant control loop to track and fix. since applications are stateless, there is no backup/recovery/restore of state. for-example if a instance of webserver crashes, controller can easily replace that with another instance of webserver and bring it back to desired state.
But for stateful applications like databases, it’s not that straight forward, and it will require manual intervention to restore the state!!! so we need something more than standard controllers.

Since the introduction of the Custom Resources, we have the flexibility to declare and create our own k8s resources.

Now imagine if we can start defining our own resources and letting the k8s also manage them!!!! and even better imagine, if we can build our own controllers to have our own custom manage logic, and letting k8s run our resources!!!…and that is what is “Operators”!!!

With Operators, we should be able to write the logic for complete management of custom resources, and let k8s manage our resources!!!..and that's how we can move to low-touch ops!!!

so what all can we automate with operators…the answer is “everything that can be automated”…right from installation, patching, updates, upgrades, backup, recovery, capturing telemetry, and acting based on AI (artificial intelligence to the nirvana stage of zero-touch ops.

There is a very well defined Operators maturity model, that clearly defines the 5 phases of maturity.

There are 3 main components of Operators Framework

Operators SDK: provides the tools to build, test, and package the Operators. Provides 3 SDK out of the box

Helm SDK: provides a declarative way of building Operators, with this mainly install and configure kind of Operators can be built
Ansible SDK, Go SDK: Ansible and GO SDKs provide more advanced ways of building the Operators. where you can build Operators all the way to “Auto-Pilot” maturity.

Apart from Operators SDK — there are some tools in the market such as KUDO, kubebuilder, Metacontroller

Operator Lifecycle Manager (OLM): manages the complete lifecycle of the Operator — installing and managing the Operator. OLM monitors the CRD that is deployed and when something changes..then it ensures that the changes are applied across the cluster

Operator Metering: reports the usage of the operator to help the metering

Creating & Deploying an Operator

Here is a quick walk-thru of building and deploying an Operator. Just for the completeness, I thought I will do a very quick walk-thru

AIOps for Zero-Touch Ops

Artificial Intelligence & applying machine learning for ITOps has become a reality and has already become a very common practice to bring down the operational cost. So what capabilities are required for AIOps???

The picture above illustrates my understanding of AIOps capability architecture. (thanks Naveen E P for brainstorming and contribution in building this nice picture).

AIOps goes beyond standard event detection to advanced prediction with actionable insights. The term “actionable” is important — it’s the recommendation or execution of the best action to fix the current or issues that might occur based on prediction. This is what we really need for an “Auto-Pilot” Maturity, where it will replace or augment Site Reliability Engineers (SRE).

Now if you connect this generic picture of AIOps with what k8s Operators bring to the table, it is very clear that the operators have all that we need to be our AIOps engine.

All the various types of capabilities can be built as a CRs, and can be a bunch of operators that will bring all the pieces of AIOps to life, these operators co-locate inside the K8s cluster and run as PODs/Sidecars. They can also integrate with ServiceMesh for additional metrics and telemetry, and act proactively and operate the cluster.

The above picture provides a high-level view of the idea, and let's see how it maps to the 3 layers that we talked on the AIOps capability architecture

Visibility: Visibility layer can be built on Grafana, providing single pane visibility of the cluster health
Prediction: Prediction layer has all the modules (python modules to advanced spark clusters as specific operators), that build machine learning models from the data that is streaming from Prometheus, ServiceMesh/istio.
Resolution: Resolution can be simple k8s commands to Ansible playbooks or even invoking RPA digital works — depending on standard operating procedures, to recover the failures or take proactive measures

The best part is all of this AIOps is happening native to Kubernetes (except maybe RPAs)

There you go, Operators is the key to unlock the “Zero-Touch Ops” Journey.

In the meantime, I have been playing around with operators and will soon come back with a hands-on session…

Have fun, take care..ttyl

References

Evolution of k8s worker nodes-CRI-O

A B Vijay Kumar — Thu, 20 Jan 2022 05:58:35 +0000

Evolution of k8s worker nodes-CRI-O

Just a few months back, I never used to call containers as containers…I used to call them docker containers…when I heard that OpenShift is moving to CRI-O, I thought what's the big deal…to understand the “big deal”…I had to understand the evolution of the k8s worker node

Evolution

If you look at the evolution of the k8s architecture, there has been a significant change and optimization in the way the worker nodes have been running the containers…here are significant stages of the evolution, that I attempted to capture…

Stage 0 : docker is the captain

It started with a simple architecture of kubelets as the worker node agents that receive the command from admins, through api-server from the master node. The kubelets used docker runtime to launch the docker containers (pulling the images from the registry). This was all good…until the alternate container runtimes, with better performance & unique strengths, started appearing in the market, we realised that it would be good if we can plug and play these runtimes...the obvious design pattern we would use to fix this issue is ??? “adapter/proxy” pattern…right?? that led to the next stage.

Evolution is all about adapting to the changes in the ecosystem

Stage 1: CRI (Container Runtime Interface)

Container Runtime Interface (CRI) spec was introduced in K8s 1.5. CRI also consists of protocol buffers, gRPC API and libraries. This brought the abstraction layer, and acted as an adapter, with the help of gRPC client running in kubelet and gRPC server running in CRI Shim. This allowed a simpler way to run the various container runtimes.

Before we go any further…we need to understand what all functionality is expected from container runtimes. Container runtime used to manage. downloading the images, unpacking them, running them, and also handle the networking, storage. It was fine… until we starting realizing that this is like a monolith!!!

Let me layer these functionalities into 2 levels.

High level — Image management, transport, unpacking the images & API to send commands to run the container, network, storage (eg: rkt, docker, LXC, etc).
*Low Level *— run the containers.

It made more sense to split these functionalities into components that can be mixed and matched with various open-source options, that provide more optimizations and efficiencies…the obvious design/architecture pattern we would use to fix this issue is ??? “layering” pattern…right?? that led to the next stage.

Stage 2: CRI-O & OCI

So the OCI (Open Container Initiative), came up with a clear container runtime & image specification, which helped multi-platform support (Linux, Windows, VMs etc). Runc is the default implementation of OCI, and that is the low level, of container runtime.

The modern container runtimes are built on this layered architecture, where Kubelets talk to Container Runtimes through CRI-gRPC and the Container Runtimes run the containers through OCI.

There are various implementations of CRI such as Dockershim, CRI-O, containerD.

Towards the end of Stage 1, I mentioned the flexibility to create a toolkit for end to end container management… and that needed Captain America to assemble the avengers, to provide an end to end container platform…

Avengers of k8s world - led by Captain “OpenShift”

podman: deamonless container engine, for developing managing and running OCI containers, and speaks exact docker CLI language, to the extent where u can just Alias it
skopeo: a complete container management CLI tool. One of the best features I love about skopeo, is the ability to inspect the images, on the remote registry, without downloading or unpacking!!!…and it matured into a full-fledged image management tool for remote registries, including signing images, copying between registries & keeping remote registries in sync. This significantly increases the pace of container build, manage and deploy pipelines…
buildah: a tool that helps build the OCI images, incrementally!!!..yes incrementally…I was playing around this the other day. I don’t have to imagine the image composition, and write a complex Dockerfile..instead, I just build the image one layer at a time, test it, rollback (if required), and once I am satisfied, I can commit it to the registry…how cool is that!!!
cri-o: light-weight container runtime for k8s…will write more about this in the next section.
OpenShift: End to end container platform…the real Captain!!

Red Hat OpenShift goes for CRI-O

Red Hat OpenShift 4.x defaults to CRI-O as the Container runtime. A lot of this decision (in my opinion) goes back to the choice of building an immutable infrastructure based on CoreOS, on which the OpenShift 4.x runs. CRI-O was obvious with CoreOS as the base, and all the more, CRI-O is governed by k8s community, completely Open Source, very lean, directly implements k8s container runtime interface…refer these 6 reasons in detail

Here is a great picture taken from this blog, that shows how CRI-O works under the wood in Red Hat OpenShift 4.x

References

OpenShift 4 “under-the-hood”

A B Vijay Kumar — Wed, 19 Jan 2022 04:39:13 +0000

OpenShift 4 “under-the-hood”

I have been playing around with Red Hat OpenShift 4.x for the past few months now… It has been a super exciting learning journey…In this blog, I will attempt to capture the key architectural components of OpenShift 4.x and how they come together, to provide the most comprehensive container platform.

… let's open the hood…

Nuts and Bolts

**Built on CoreOS: **According to me, this is one of the major architectural changes in OpenShift 4.x. and I think it really changed the way platform works…here is how!!!

CoreOS provides “immutability”!!!…what does that even mean…let me explain…while Red Hat CoreOS is built on RHEL components (brining in all the security and control measures)..CoreOS allows you to modify only a few system settings, and make it much easier to manage upgrades & patches. This immutability allows OpenShift do better state management and perform updates based on the latest configurations.

so what's the big deal??..here are the top reasons, why I think its a big deal

Versioning and rollbacks of deployments are much easier & straight forward — so the DevOps process is much more manageable.
“Configuration Drift” is a big issue, if you have managed a large number of containers/MicroServices, in a HA/DR environments. Typically container infrastructure is built by a team and over a period of time is managed by various engineers. There are always situations, where we are forced to change the configuration of the VMs/Containers/OS, that we may never trace back.
This causes a gap between Production & DR/HA environment. I read somewhere that up-to 99% of HA/DR issues are caused due to this..and in my experience a Core Banking System, went down for days, before we could even figure out that the root-cause was configuration gaps between Prod & HA/DR.
Immutability helps us do better version control of the infra — We will have more confidence in testing, as the underlying infrastructure on which our application containers are running, is immutable, and we are very sure about the test results, and more confident.

Vertically Integrated stack with CoreOS: *In *OpenShift 4.x, CoreOS is vertically integrated with the Container platform…what it means is that the cluster can now manage the pools of Red Hat CoreOS machines (nodes), and its full lifecycle, in k8s style!!!. Imagine how it will reduce the operational effort!!!, just to compare with OpenShift 3.x — we used to manually provision OS and rely on the administrators to configure the OS properly and more importantly manage the updates & upgrades.

To my earlier point, this also caused a lot of issues due to “Configuration Drifts” over a period of time…you will see how this vertical integration will help setup & manage Nodes as “Machines” later in the blog.

CRI-O as the container runtime: I had published a blog on “why CRI-O”…please read this blog. But in my personal opinion, this is another very critical architectural decisions that make OpenShift 4.x more agile, light-weight, scalable, and high performing container platform.

Operators: This is another important component of the architecture…which allows us to extend the k8s and customize the resources and controllers & and build a more manageable system…please read my blog on operators, where I go deeper.

Machine Management: Machine Management is one of the most important ecosystem of resources & operators in OpenShift 4.x. These resources and operators provide a comprehensive set of APIs for all node host provisioning & works with the Cluster API for providing the elasticity & autoscaling

Machine: Machine is the fundamental unit that represents the k8 node, which abstracts the cloud platform “specific” implementations. The machine “providerSpec” describes the actual compute node, that gets realized. MachineConfig defines the machine configuration,
MachineSets: Like how replicaSets manage the replicas, and ensure and maintain the “Desired state”, MachineSet ensure the desired state of a number of machine (nodes) that are running
MachineAutoScaler: MachineAutoScaler works with MachineSets to manage the load and automatically scale the cluster. The minimum and maximum number of machines are set in MachineSet, and MachineAutoScaler manages scalability
ClusterAutoScaler: This ClusterAutoScaler manages the cluster wise scaling policy based on various cluster-wide parameters such as cores, memory, GPU, etc.

As we walk through the blog, you will see more and more nuts and bolts coming together to build the most advanced container platform

Provisioning

OpenShift 4.x introduced a more sophisticated and automated installation procedure, called Installer-provisioned Infrastructure, which does a full-stack install — leveraging the Ignition & Operator. There are 2 ways to install

Installer-provisioned Infrastructure (IPI): This is only available for OpenShift 4.x, This provides a full-stack installation and setup of the cluster, including the cloud resources and the underlying Operating system, which in this case is RHEL CoreOS.

User-Provisioned Infrastructure (UPI): UPI is the traditional installation, that we had since OpenShift 3.x, where we need to set up the underlying Infrastructure (Cloud Resources & OS), and openshift-install can help automatically set up the cluster & cluster services.

Apart from this, OpenShift is also available as a managed service offered by most of the hyper-scalers IBM, AWS, Azure, GCP

Ignition is the most important utility, that has powerful capabilities to manipulate disks during the initial setup, it reads from the configuration files (.ign) and creates the machines, It makes the provisioning process, super easy…

Lets now see how the Ignition works in setting up the full cluster.

In the above picture, you can see how Ignition configuration files (.ign) are used by the bootstrap machine (read machine=node in OpenShift 4.x), that spins off the master nodes, replicates etcd, merging the base ignition configuration and any other user customized configurations, which in turn spin off the worker nodes, using worker and master configurations.

Updates & Upgrades

OpenShift 4.x provides seamless updates, over-the-air. This is possible because of the integrated CoreOS, and the magical MachineConfig Operator. Here is how it works

MachineConfig Operator manages the configuration changes across the cluster. Before we try to understand how the updates and upgrades, let's understand the key components of this Operator, that come together

MachineConfig Controller: This runs on master and orchestrates updates across clusters.
MachineConfigServer: This hosts the ignition config files, that provision any new nodes.
MachineConfig Daemon: This runs on every worker machine (its a daemonset), and is responsible to manage updates on worker machines.
MachineConfig is a k8s object, that is created by bootstrap ignition, and it represents the state of the machine.
MachineConfigPool is the group of machines of a particular type., like a master machine, worker machine, infrastructure machine etc.

The changes to the system happens through the changes in the MachineConfig. Any changes in the MachineConfig is rendered and applied to all the machines in a MachineConfigPool.

So if I have to change a configuration of a type of machine (node), I apply the change to the MachineConfig, which is picked up by MachineConfig Controller, that co-ordinates with MachineConfig Daemons.

The MachineConfig Daemons, pulls the MachineConfig changes, from the API server, and applies to their respective machines (nodes). If the change is an upgrade, it would connect to the quay.io registry to pull the latest image, and applies it.

MachineConfig Daemons sequences and drains the node/machines, and reboots them, after applying the changes...

The updates can be applied OTA (over-the-air) using either the admin console or cloud.openshift.com web interface. The release artifacts are packaged as container images, as a single package. ClusterVersion Operator, checks with OCP Update Server (hosted by Red Hat), and then connects to the Red Hat hosted Quay.io, to pull the image, and works with Cluster Operators for rolling out the upgrades.typical application level upgrades are managed by OLM operators

…and that is how OpenShift provides a sophisticated & controller way to do the updates and upgrades across the cluster.

Runtime

Now, let's explore how OpenShift 4 architecture looks in runtime…The below diagram shows how the Master and Worker nodes are stacked…

…and the below diagram, illustrates how the deployment architecture looks at a high-level…if you look closer, the Infra workloads are provisioned separately, from the app workloads. This helps in reducing the load on the application worker machine. The Infrastructure MachineSet takes care of

Just to make more practical sense of the above diagram, if you run an IPI on AWS…here is a how the typical cluster would look like, from the topology perspective…

6 EC2: 3xMaster nodes, 3xWorkers nodes
2 Route53 Configurations: 1xAPI Server, 1xApp domain
3 ELB: 1xInternal API Load balancer, 1xExternal API Load balancer: 6443 port traffic is the target group of 3 masters — API traffic, 1xApplication Load balancer — This is configured to 3 worker nodes
2 security groups: One for master, One for worker
All of them in a VPC

you can see a detailed AWS deployment architecture here, similarly, you can refer to the respective hyper scalers.

Scaling

OpenShift 4.x out-of-the-box supports both auto and manual scaling. Each of the nodes are configured as Machine resources, and the MachineSet manages multiple machines.

One MachineSet is configured per availability zone. MachineSet ensures the “desired state” of the number of machines (nodes).

In the case of manual scaling, The MachineSet configurations can be edited to increase the number of machines.

In case of auto-scaling, MachineAutoScaler automatically scales the MachineSet desired state up and down, and limits between the minimum and maximum number of the machine that is configured, and ClusterAutoScaler decides the scaling up and down based on various parameters such as CPU, memory, etc. All of this works independently of underlying cloud infrastructure!!! 😎. The diagram below illustrates how it works.

DevOps

Now moving to the most important part of the SDLC — DevOps. There are 2 key components that help improve the developer experience for rapid development and deployment in OpenShift 4.x

CodeReady Workspace

CodeReady workspace is based on Eclipse Che, which brings a completely integrated web-based development environment and seamless integration with the OpenShift platform. It also comes pre-packaged with various development environment template for polyglot development & deployment. How cool is that!!!

Native CI/CD

Moving beyond Jenkins, OpenShift 4.x brings the cloud-native CI/CD with Tekton, which runs within K8s. Tekton runs completely serverless, with no extra load on the system.

I will be covering more in detail about Tekton and GitOps soon in a separate blog, will leave a link, here once done!!!

Both CodeReady Workspaces and Tekton and pipelines are available as Operators in OperatorHub…so just click and install…

Ops

Managing cloud application is the most critical, as the number of MicroServices grow, and the deployments grow, it becomes very important to have a integrated management platform, that supports

Observability (with Grafana and Prometheus)
Traceability (with Kiali and Jaeger)
Canary Deployments & Rolling Updates (with Istio)
API routing & Management (with Istio )

OpenShift ServiceMesh provides a complete management solution, that is highly extendable to integrate with the larger enterprise Ops…also check out my other blog on Operators, on how we can achieve zero-touch ops here

There you go..this is really the enchilada of container world 🌐

This is not all, there is a lot more, such as: how OpenShift abstracts the storage with Red Hat OpenShift Container Storage, and how it abstracts the underlying cloud platform network with Networking Operator- CNO and CNI, and the most important feature of Multi-cluster management.

I will soon be publishing a blog on Multi-cluster management, I will be covering in detail, and will be leaving a link on the blog, when published…

phew!!! that's a lot for one blog…

I hope it now makes sense, why we need a container platform like OpenShift…imagine, it will be a nightmare if I had to “DYI” with k8s and a bunch of OpenSource libraries. 😳

The only downside of OpenShift is that it is an “opinionated full-stack” platform…if you think about it!!! we need a container platform to run business-critical workloads..(personally, I always love to build my own stack, and play around with it…but can’t risk experimenting with serious enterprise applications)

in the meantime…you can play around with OpenShift with a free trial, or install it on ur laptop with CodeReady Containers from here (your laptop might need a good cooler :-) )…

Enjoy!!! stay safe..ttyl…

*Subscribe to FAUN topics and get your weekly curated email of the must-read tech stories, news, and tutorials *🗞️

Follow us on Twitter **🐦 and Facebook *👥 **and Instagram *📷 *and join our Facebook and Linkedin Groups *💬

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author! ⬇

References

Java Serverless on Steroids with fn+GraalVM Hands-On

A B Vijay Kumar — Tue, 18 Jan 2022 12:26:34 +0000

Java Serverless on Steroids with fn+GraalVM Hands-On

Function-as-a-Service or Serverless is the most economical way to run code and use the cloud resources to the minimum. Serverless approach runs the code when a request is received. The code boots up, executes, handles the requests, and shuts down. Thus, utilizing the cloud resources to the optimum. This provides a high, available, scalable architecture, at the most optimum costs. However, Serverless architecture demands a faster boot, quicker execution, and shutdown.

GraalVM native images (ahead of time) is the best runtime. GraalVM native images have a very small footprint, they are fast to boot & they come with embedded VM (Substrate VM).

I had blogged about GraalVM here. Please refer to the following blogs, for better understanding of the architecture of Graal VM and how it builds on top of Java Virtual Machine
*Episode 1: “The Evolution” *— Java JIT Hotspot & C2 compilers (the current episode…scroll down)
*Episode 2: “The Holy Grail” *— GraalVM
In these blogs, I will talk about how GraalVM embraces polyglot, providing interoperability between various programming languages. I will then cover how it extends from Hotspot, and provides faster execution, and smaller footprints with “Ahead-of-time” compilations & other optimisations

fn Project

fn project is a great environment to build serverless applications. fn supports building serverless applications in Go, Java, JavaScript, Python, Ruby, C#. It is a very simple and rapid application development environment that comes with fn daemon & a CLI which provides most of the scaffolding to build serverless applications.

In this blog let's focus on building a simple KG to Pounds converter function in Java. First, we will build a serverless application with Java, and then later build it using GraalVM native image. We will then compare how fast and small GraalVM implementation is.

Prerequisite

Install docker (refer to https://www.docker.com/ for latest instructions)
Install fn (refer to https://fnproject.io/ for latest instructions)

1. Starting fn daemon

Start the fn daemon server using fn start

The fn server runs in docker, you can check that by running docker ps The screenshot below shows, what I am able to see in my computer.

2. Generating the fn boilerplate code

Now we can generate the boilerplate code with

fn init --runtime java converterFunc

This creates a folder converterFunc with all the boilerplate code

cd converterFunc

Let’s inspect what is inside that folder. You will see a func.yaml, pom.xml & a src folder

func.yml is the main manifest yaml file that has the key information about the class that implements the function and the entry point. Let's inspect that

schema_version: 20180708
name: converterfunc
version: 0.0.1
runtime: java
build_image: fnproject/fn-java-fdk-build:jdk11-1.0.118
run_image: fnproject/fn-java-fdk:jre11-1.0.118
cmd: com.example.fn.HelloFunction::handleRequest

name: The name of the function, we can see the name of the function that we specified in our command line fn init
version: Version of this function
runtime: Java Virtual machine as the runtime
build_image: The docker image that should be used to build the java code, in this case, we see its JDK 11
run_image: The docker image that should be used as a runtime. In this case, it is JRE11
cmd: This is the entry point, which is the ClassName:MethodName

fn has all the information that it needs in this yaml to build and run the function when it is invoked.

Now let's look at the maven file (pom.xml).

We see the repository from where the fn dependencies are to be pulled

and the dependencies com.fnproject.fn.api, com.fnproject.fn.testing-core, com.fnproject.fn.testing-junit4.

In the src the folder we will find HelloFunction.java, which is the default boilerplate code that is generated by fn.

The code is very straightforward. It has a handleRequest () method, which takes in the String an input and returns String as an output. we can write our function logic in this method. This is the method that fn, calls when we invoke the function.

3. Writing our logic

Let's build our converter application. I am going to deploy it into the path src/main/java/com/abvijay/converter , and the name of my Class is ConverterFunction.java

The code is very straightforward. I am just expecting a kgs value in String, converting that to Double and calcualting pound value and returning that back as a String. ( I did not write a lot of exception handling, to check for edge conditions, to keep it simple).

Now we need to update the func.yaml to point to our new Class

Check line number 7, Which is changed to point to the new class and method.

4. Build & Deploy the serverless container to the local docker

Functions are grouped into applications. an application can have multiple functions. That helps in grouping them and managing them. So we need to create a converter-app

fn create app converter-app

Once the app is created, we can now deploy the app.

fn deploy --app converter-app --local

fn deploy command will build the code using maven, package it as a docker image, and deploy it to the local docker runtime. fn can also be used to deploy to the cloud or k8s cluster directly.

Lets now use docker images command to check if our image is built.

We can also use fn inspect to get all the details about the function, this helps in the discovery of the services.

fn inspect function converter-app converterfunc

5. Running and Testing

Now lets invoke the service, since our function expects a input argument in number, we can pass it using a echo command and pipe the output to fn invoke to invoke our function

echo -n ‘10’ | fn invoke converter-app converterfunc

We can see the result coming from the function. Now let's run the same logic on GraalVM

6. Run on GraalVM, as a native-image

The base image for GraalVM is different, we use fnproject/fn-java-native-init, as the base, and initialize our fn project with that

fn init --init-image fnproject/fn-java-native-init converterfuncongraal

cd cnverterfuncongraal

This fn configuration works differently. It also generates a Dockerfile, with all the necessary docker build commands. This is a multi-stage docker build file. Lets inspect this dockerfile

line 17: The image will be built using fnproject/fn-java-fdk-build .
line 18: setting the working directory to /function
line 19–23: Then the maven environment is configured.
line 25–40: Using base image as fnproject/fn-java-native, the GraalVM is configured and fn runtime is compiled. This is a very important step, this is what makes our serverless runtime faster and with smaller footprint.
line 43–47: Using busybox:glibc (which is the minimal version of linux+glibc) base image the native images are copied.
Line 48: is the function entry point. the func.yml in this way of building the serverless image has no information. fn will use dockerfile to perform the build (along with maven) and deploy the image to the repository

Now we need to change line 48 to point to our class. let's replace that with

CMD [ “com.abvijay.converter.ConverterFunction::handleRequest” ]

Another important configuration file, that we need to change reflection.json under src/main/conf This json file has the manifest information about the class name and the method.

Let's change that to

now let’s create a new app and deploy this app and run and see

fn create app graal-converter-app
fn deploy --app graal-converter-app --local
echo -n '20' | fn invoke graal-converter-app converterfuncongraal

There you go, our code is now running on GraalVM. So what's the big deal. When I ran docker images , I see the size of the Java image as 223 MB and the GraalVM image is just 20MB. That is a 10 times smaller footprint.

When I timed the function calls, the Java function took around 700ms while GraalVM took around 460ms. That is almost 30% faster. For functions with more complex logic, the differences will be much more significant.

Java hotspot might catch up with this number, but that is provided the function runs longer, and the Just in time Compiler kicks in to optimize the code. Since most of the functions are expected to be quick and short running, it does not make sense to compare these JIT benchmarks.

There you go…I hope this was fun…ttyl :-)

References:

Platform Engineering with Pulumi — Episode 3: Platform & Application Deployment with GitOps Automation

A B Vijay Kumar — Tue, 18 Jan 2022 12:21:50 +0000

Platform Engineering with Pulumi — Episode 3: Platform & Application Deployment with GitOps Automation

Automate the deployment of the app with GitActions and CodeDeploy.

In Episode 1 of this blog series, we built an AWS landing zone for our React/Node.js application, using Pulumi. In Episode 2 we built a simple React app and an Express API server. We manually deployed the app on the landing zone. In this episode, we will automate it with GitActions and CodeDeploy.

For the sample application used in this blog, I have used Multi-repo. There is a huge debate on Mono vs Multi Repos. I might blog about that separately, but for now let's assume Multi repo is the best for this application and go ahead :-D.

Before we configure the GitActions, we have to modify the infrastructure code to include Infra code for the creation of code deploy configurations.

Modifying the Infra code to create CodeDeploy

In Episode 1, we did not create the CodeDeploy Configurations. Find below the modifications done in the Python code to create appropriate Roles and CodeDeploy configurations. Let's walk through the code (please refer to my **GitHub* for more latest code.*)

In the above code, We are creating a Role, to allow the CodeDeploy service to have access, and attaching appropriate access policies (AmazonEC2FullAccess, AWSCodeDeployFullAccess, AdministratorAccess, AWSCodeDeployRole).

Let's now create the CodeDeploy application

In the above code, we are creating a CodeDeploy application. Let's now create deployment groups.

In the above code, we are creating a CodeDeploy Deployment Group, with the Role that we created. This deployment group will be used to deploy API code (Node.js/Express). The below code created a CodeDeploy Deployment Group to deploy the React application. Both the deployment groups are created under the same CodeDeploy Application

Let's now run the code withpulumi up.

GitOps Deploying Node.js API application

Now that we have all the infrastructure ready.

Lets first create a CodeDeploy Configuration file (appspec.yml) in our Node.js application.

In the appspec.yml, we are configuring the source and destination (on EC2) folders. This configuration is used by CodeDeploy to deploy the application files in the appropriate folder (/home/ec2-user/contacts-api).

We are also configuring 2 Hooks

Before Install Hook: This is a shell script that we are asking CodeDeploy to run, before deploying the application code. In this shell script, we will set up the environment required. The following is the code for setup.sh. In this shell script, we are installing NVM and creating a directory for CodeDeploy to deploy the source files:

Application Start Hook: Which is another shell script that we are asking CodeDeploy to run to start the application after deploying the application code. The following is the code for appStart.sh, where we are setting up the nvm environment variables, running npm install to install all the dependencies, and then running our application.

Let's now build a GitOps pipeline for the NodeJS application. The following is the code for GitActions, which gets triggered on pull request and push.

The above code is very simple. We are using a ubuntu-latest VM instance, setting the AWS credentials (the AWS_IAM_ACCESS_KEY, AWS_SECRET_ACCESS_KEY and AWS_REGION configurations are already configured in GitHub under Settings->Secrets. Here is a screenshot).

We are then triggering the appropriate CodeDeploy deployment group, that we have configured using Pulumi in the above section.

Now that we have all the pipeline code, let's test it by running the GitActions Workflow. The following animated gif shows the execution of the workflow and the deployment.

Let’s now automate the deployment of the React app.

GitOps Deploying React application

To deploy React, the steps are similar, We first configure the AWS key, region, and secret in GitHub secrets.

Let's create the GitActions workflow. The following is the code:

This code is very similar to how we deployed Node.js except that the deployment group we are using for React is different. We are using pulumi-blog-app-codedeploy-deploymentgroup.

Let's add the appspec.yml in the React root folder. The following is the source code. Similar to what we did with the Node.js application, we have 2 hooks, one to set up the environment and the other script to start the application.

Let's create the startup.sh, where we set up the environment before we deploy the application.

In the above code we are installing nvm, and making sure contacts-app the folder is created.

The following is the code for running the application.

In the above script, we are installing pm2 & serve, building the application, and running the application. These are the exact steps we followed in Episode 2.

Let's now execute the workflow. The following is the screen capture video of the workflow execution.

Now we have all the pipelines configured whenever there are changes to the application code, the respective GitAction workflow will deploy the application to the EC2 instance.

We need one more GitOps pipeline for the Infrastructure code. I thought of covering that in this episode..but it has already become a long one. So I will be publishing the same in the next Episode.

Until then take care and Have fun, hope this was helpful :-D

References

React app Repository: https://github.com/abvijaykumar/contactlist-blog-react-app
Express API repo: https://github.com/abvijaykumar/contactlist-blog-app
Pulumi Infrastructure code repo: https://github.com/abvijaykumar/contactlist-blog-infra
**community Discord*.

Building GraalVM Native Image of a Polyglot Java+numpy application

A B Vijay Kumar — Sun, 16 Jan 2022 13:50:36 +0000

Building GraalVM Native Image of a Polyglot Java+numpy application

One of the greatest features of GraalVM is to provide a universal runtime for running code written in different languages. This opens up a huge opportunity to reuse the existing tested and hardened code, without rewriting it in target languages. This is very handy at times where code is tough to migrate, or the host language has features that make it an obvious choice to implement. For example, Python and R are known for the right libraries, and the simplicity they provide in building data science and machine learning applications.

Before I get into the actual topic, let me introduce GraalVM. Here are some blogs on GraalVM, I had published before.

Episode 1: “The Evolution” — Java JIT Hotspot & C2 compilers (the current episode…scroll down)
*Episode 2: “The Holy Grail” — GraalVM*
*Java Serverless on Steroids with fn+GraalVM Hands-On*
This blogs provides a hands on example of how to build a serverless application using fn project and run it on GraalVM

I also blogged about what is inside the book here. Supercharge Your Applications with GraalVM — Book

You can check out the book at these links

In this blog, we will explore how we can use the GraalVM Polyglot library to call a python program, that uses numpy, from a Java application.

This python program performs a simple data analysis of a dataset that I picked from Kaggle (https://www.kaggle.com/rashikrahmanpritom/heart-attack-analysis-prediction-dataset).

This dataset has records of people who had a heart attack and various important information about these patients, which will help us do some data analysis to identify patterns.

Before we get hands-on, we need to understand the Polyglot architecture of GraalVM. GraalVM comes with a framework called “Truffle”, which allows polyglot interoperability on GraalVM.

GraalVM Polyglot Architecture — Truffle

Truffle is an open-source library that provides a framework to implement language interpreters. Truffle helps run guest programming languages that implement the framework to utilize the Graal compiler features to generate high-performance code. Truffle also provides a tools framework that helps integrate and utilize some of the modern diagnostic, debugging, and analysis tools.

Let’s understand how Truffle fits into the overall GraalVM ecosystem. Along with interoperability between the languages, Truffle also provides embeddability. Interoperability allows the calling of code between different languages, while embeddability allows the embedding of code written in different languages in the same program.

Language interoperability is critical for the following reasons:

Different programming languages are built to solve different problems, and they come with their own strengths. For example, we use Python and R extensively for machine learning and data analytics, and we use C/C+ for high-performance mathematical operations. Imagine if we would reuse the code as it is, either by calling the code from a host language (such as Java) or embedding that code within the host language. This also increases the reusability of the code and allows us to use an appropriate language for the task at hand, rather than rewriting the logic in different languages.
Large migration projects where we are moving from one language to another can be phased out if we have the feature of multiple programming language interoperability. This brings down the risk of migration considerably.

The following figure illustrates how to run applications written in other languages on GraalVM:

In the figure, we can see GraalVM, which is the JVM and Graal JIT compiler that we covered in the previous chapters. On top of that, we have the Truffle framework. Truffle has two major components. They are as follows:

Truffle API: The Truffle API is the language implementation framework that any guest language programmers can use to implement the Truffle interpreter for their respective languages. Truffle provides a sophisticated API for Abstract Syntax Tree **(AST**) rewriting. The guest language is converted to AST for optimizing and running on GraalVM. The Truffle API also helps in providing an interoperability framework between languages that implement the Truffle API.
Truffle optimizer: The Truffle optimizer provides an additional layer of optimization for speculative optimization with partial evaluation. We will be going through this in more detail in the subsequent sections.

Above the Truffle layer, we have the guest language. This is JavaScript, R, Ruby, and others that implement the Truffle Language Implementation framework. Finally, we have the application that runs on top of the guest language runtime. In most cases, application developers don’t have to worry about changing the code to run on GraalVM. Truffle makes it seamless by providing a layer in between.

Truffle provides the API that the individual interpreters implement to rewrite the code into ASTs. The AST representation is later converted to a Graal intermediate representation for Graal to execute and also optimize just in time. The guest languages run on top of the Truffle interpreter implementations of the respective guest languages. To read and understand mode about how Truffle works, Please refer to my book

Hands-On — Java & Python Interoperability

The dataset has various columns, the key columns are age, sex, chest pain, cholesterol levels, etc. The following is the screenshot of the dataset

Lets now build a simple numpy module (in python) that calculates the average age of people who have level 3 chest pain, and people with level 3 chest pain. And then we will be calling this python method from Java.

Step 1: Setup Environment

Let's first start with installing GraalVM. You can refer to GraalVM Documentation on installing it on your target OS. I always prefer using VisualStudio Code, as it provides a great integrated environment and helps manage the environment and different versions of GraalVM with ease.

You can install GraalVM on Visual Studio Code as an extension. Find below the screenshot of where you can find it on Visual Studio Code

You can install either Community or Enterprise (or both, as VSCode provides a way to have multiple environments, and provides a very easy way to switch between the environments). In my case, I am installing Community edition.

Once I install it, VSCode also helps to set the respective environment variable. This ensures that the integrated terminal points to the right version of the GraalVM. (This can be easily switched with other versions)

Once the environment is set, we also need to install the other optional runtimes. We will need Python, LLVM, Native Image runtimes. You should be able to install them by clicking the “+” button

Once all the optional runtime is installed, you can check the versions in the VSCode integrated terminal.

Let's now create a virtual environment. Instead of using, we will be using graalpython. The following is the command to create a virtual environment with graalpython

graalpython -m venv ab_venv

To activate the virtual environment we execute source ab_venv/bin/activate

Let's set the python environment variable

export GRAAL_PYTHONHOME=$GRAALVM_HOME/languages/python

Lets now install numpy. Once again we will be using graalpython command line to install the packages. The following is the command for installing numpy

graalpython -m ginstall install numpy

Step 2: Build and test Python application

The following is the python code. It's a very simple numpy API call to calculate the averages, and return the values dataOfPeopleWith3ChestPain, averageAgeofPeopleWith3ChestPain

you can find the latest code in my GitHub account here

As you can see it is a very simple python application. We are loading the CSV file (dataset that we downloaded from Kaggle), we are then performing a simple statistical calculation and returning the average age of the people who had level 3 chest pain before a heart attack.

To check if our application is running, we will use graalpython

graalpython heartAnalysis.py

you should be able to see the output from the application. Here is what I can see.

Now that we know our python application is running and we have exposed the heartAnalysis() method, let's build a Java application to call this method.

Step 3: Build and Test Java Application

Find below the Java Application that calls the Python method, that we developed in Step 2.

Lets understand this Java code

Lines 1–4: We are importing the following Java libraries

java.io.File: as we will be loading the python source code file into the application
org.graalvm.polyglot.Context: GraalVM provides a polyglot context, that helps with the interoperability between code written in different langauges. Please refer to API doc here.
org.graalvm.polyglot.Source: This class represents the source code and the contents of this. We will be using this object to access the Python methods. Please refer to the API doc here.
org.graalvm.polyglot.Value: This class represents the value that can be passed between the host and guest languages. In this case, the host is Java and the guest is Python. Please refer to the API doc here.

Line 8: We are building and initializing the polyglot context object, and setting the permission to have complete access. This object will help us load and run the python code

Line 10–11: We are loading the python source code into the context and building the code.

Line 13: We are accessing the method definition using the Binding object. In our case, we are getting the reference to heartAnalysis() python method.

Line 15–18: We are invoking the method and printing the results.

Lets us now compile the Java code and run it

javac HeartAnalysisJava.java

java HeartAnalysisJava

Here is the screenshot of my terminal, after compiling and running the Java program.

You will see 3 outputs. The first one is coming from print(averageAgeofPeopleWith3ChestPain) a statement that is called within the python code heartAnalysis(). The second output from the Java code invoking the heartAnalysis() python method and the last output is the data that Java code received from python code that we are printing with System.out.println in Line #16.

Now we have a working Java application that is invoking a python method. Let's now build a native image of this java code.

Step 4: Building Native Image

Ensure that the Native image runtime is installed, if not, you can install it using the VSCode GraalVM plugin, as shown in the screenshot below. Or you can install using GraalVM Updater utility. Please refer to the documentation here

To build the native image, let's execute the following command

native-image -language:python -Dorg.graalvm.launcher.relative.python.home=$GRAALVM_HOME/languages/python -Dorg.graalvm.launcher.relative.llvm.home=$GRAALVM_HOME/languages/llvm HeartAnalysisJava

GraalVM native-image command line is used to build the native image.

The -languageargument lets the native image know that we will be calling python code, and ensures that Python is available as a language for the image. The other 2 arguments are letting the native-image builder know where to find python runtime and the llvm runtime.

This generates a binary file heartanalysisjava, and we can run the application directly by executing the following command

./heartanalysisjava

The following is the screenshot of the build.

That's it for now, I hope you had fun playing around with GrallVM polyglot and building native images. I have gone into a great level of detail on how GraalVM works in my book Supercharge Your Applications with GraalVM — Book.

Hope this was helpful, Keep safe, Have fun, until next time :-D

References

My GitHub Repository — https://github.com/abvijaykumar/graalvm-numpy-polyglot
Installing GraalVM — https://www.graalvm.org/docs/getting-started/linux/
GraalVM — https://www.graalvm.org/

Platform Engineering with Pulumi Episode 2: Build and Deploy a React.js Application

A B Vijay Kumar — Tue, 04 Jan 2022 13:19:59 +0000

Platform Engineering with Pulumi Episode 2: Build and Deploy a React.js Application

A guide on how to build the application and deploy it manually.

In Chapter 1 of this blog (please refer here) we built an AWS landing zone for our React.js/Node.js application. In this episode, we will build the application and deploy it manually. In the next chapter, we will use GitOps based automated deployment of both the Infrastructure and application code.

The app that we will be building is a very simple web application, that creates and fetches contact details to/from DynamoDB.

In Chapter 1, we already created a DynamoDB with Pulumi. Here is the snippet of the code, that creates the DynamoDB:

The above Pulumi code in Python creates a table called contacts-table with 2 attributes ContactName and ContactNumber, with other important configurations such as hash_key, secondary_index tags etc.

Now let's build and deploy our application, on the landing zone we created with Pulumi.

Node API

To access and perform the add and fetchAll operations on the Contacts database, let's build a simple express Node.js application. You can find the source code here.

We could have used Next.js to do both API and App, but I wanted to demonstrate deploying multiple tiers (in a typical tiered web architecture). So please play along 🙏

In this Node.js application, we will expose 2 endpoints:

/fetchAllContacts: This will connect to DynamoDB and fetch all the contacts and returns as a JSON response
/addContact: This endpoint accepts the ContactName and ContactNumber as parameters and adds the record to DynamoDB

The use case and code is very simple, as our focus is more on the IaC and GitOps, I have kept the application very simple, with no security/login and serious exception and log handling, etc.

Let’s walk through the code quickly:

Line 1–5: We are importing express, to create the endpoints and cors. For the React.js application to call these endpoints, the URL domains will be different, as the ports are going to be different. So we will need to configure Cross-Origin Resource Sharing.

Line 7–11: In the above code, we are initializing the aws sdk, and setting the default region, and creating a DynamoDB Client object.

Line 17–28: We are creating an endpoint /fetchAllContacts using express, and fetching all the records from DynamoDB, using Scan. This fetches all the contacts.

Line 30–49: We are extracting the contactName and contactNumber from the request object and adding it to the DynamoDB table.

Line 56–61: We are then running the Node.js application listening on a port.

Please note that in Episode 1, we opened port 80 SecurityGroupIngress. In the recent code, this is edited to open 8081 for the Node.js applicaton and 8082 for the React.js one. Please refer to the latest Pulumi code on my GitHub.

To run the application we will have to install the dependencies and update the package.json, here are the commands:

npm install aws-sdk --save

npm install cors --save

npm install express --save

The application can be tested from the local machine by configuring AWS using aws configure and pointing it to your account, and running the Node.js application. This is not covered in the blog (to keep the blog short).

Once the application is tested, the application code can be copied to the EC2 instance by running the scp command. Here are the commands, that I executed to copy the relevant files:

scp -i rsa /Users/vijaykumarab/AB-Home/Developer/contactlist-blog/contactlist-blog-app/package.json ec2-user@3.235.60.38:/home/ec2-user/api/package.json

scp -i rsa /Users/vijaykumarab/AB-Home/Developer/contactlist-blog/contactlist-blog-app/index.js ec2-user@3.235.60.38:/home/ec2-user/api/index.js

To run the application on EC2, log in to the EC2 and run npm install to install dependencies, and run the node app (node index.js) to test if the APIs are working.

Ensure that the right ports are opened. I used export PORT=8081, before I run the node index.js and updated my Pulumi code to open that port. Please refer to the latest code on my GitHub.

Now that we have the API running. Let's build a simple React.js application to access this API, and display the results.

ReactJS App

In the ReactJS app, we are building a simple SPA (Single Page Application). You can refer to the complete code on my GitHub. Let's quickly walk you through the application code.

To keep it simple, I am using Material UI (my personal preference is Tailwind CSS).

Line 11–17: In the above code, we are using useEffect() to fetch all the records from DynamoDB, and when the records are fetched, calling the setContacts, to refresh the page to force a render, using useState() hook.

Line 59–73: In the above code, we are defining a JavaScript Method to add a contact. This picks the values provided in the form (the code is below) and calls theaddContact endpoint to add the contact. It then refreshes the page (There are better ways to refresh the page. But to keep the code quick and simple, I am using location.reload(), which is not a good practice. Ideally, we should be using a state)

Line 78–95: In the above code, we are rendering the fetches contacts as a table.

Line 96–115: In the above code, we are rendering a form, that accepts Contact Name and Contact Number, and calls the addContact() method.

To deploy the code, let's copy the React.js code using SCP. The following are the commands, I executed:

scp -i rsa -r /Users/vijaykumarab/AB-Home/Developer/contactlist-blog/contactlist-blog-react-app/src ec2-user@54.85.92.194:/home/ec2-user/contacts-app/src

scp -i rsa -r /Users/vijaykumarab/AB-Home/Developer/contactlist-blog/contactlist-blog-react-app/public ec2-user@54.85.92.194:/home/ec2-user/contacts-app

scp -i rsa -r /Users/vijaykumarab/AB-Home/Developer/contactlist-blog/contactlist-blog-react-app/package.json ec2-user@54.85.92.194:/home/ec2-user/contacts-app

Before we build the application, let's install nvm, pm2 and serve.

And execute the following command to install nvm (please refer to the latest documentation on nvm):

curl -o- [https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh](https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh) | bash

. ~/.nvm/nvm.sh

Execute nvm install nodeto install node. To check if the node is installed, run node --version.

To install pm2 and serve execute the following commands:

sudo npm install -g pm2

sudo npm install -g serve

Once all the packages are installed successfully, let's install the application dependencies, and build our React.js app, by executing the following commands:

cd contacts-app

npm install

npm run build

I faced a strange problem when I try to run the npm run build. I was getting Error: error:0308010C:digital envelope routines::unsupported
I found the workdaround from (https://stackoverflow.com/questions/69692842/error-message-error0308010cdigital-envelope-routinesunsupported). Thanks to Peter Mortensen

The above screenshot shows the code compile. Let’s now run the application using pm2, by running the following commands:

pm2 serve build/ 8082 — name “contactlist-app” — spa

To check if our application is running let's run pm2 list.

Let's now go to the browser and check if the application is running. Following is the screenshot I got on my browser:

As you can see, manual deployment is very painful and messy. In the next chapter, we will automate all of this using GitActions and AWS CodeDeploy, so that when we push any changes to the Git (or do pull requests), the code automatically gets deployed.

You can access the complete source code on my GitHub.

You can find the API code (express code) here and ReactJs app code here

Hope this was helpful, let’s meet in the next blog…until then stay safe, and have fun, take care.

Platform Engineering with Pulumi- Episode 1: Building the AWS Landing Zone with Pulumi

A B Vijay Kumar — Mon, 03 Jan 2022 05:12:25 +0000

In this blog, I will cover some key concepts and architecture of Pulumi. We will be building and provisioning the AWS landing zone.

Platform Engineering with Pulumi- Episode 1: Building the AWS Landing Zone with Pulumi

I have been learning Terraform, Ansible, Vagrant, etc to step into IaC, Writing Infrastructure code declaratively, and creating landing zone infrastructure, with a single click, is magic.

However, I wonder, Is Terraform the ultimate tech for IaC?? Coming with an application developer background, and entering the full-stack cloud developer — learning another language and syntax is painful.

GitOps & Configuration Management: I see more and more we are treating infrastructure code as application code, where we have a CI/CD pipeline, with continuous testing requirements. We need strict configuration management, and change management governance on IaC (sometimes stricter than Application Code to avoid Configuration Drift (I explained this problem in my other blog here)).

Logic: Sometimes I want to use conditional statements, control flows (such as loops) while writing IaC, which I could do easily with application programming languages. I had to learn YAML, JSON, and remember the complex semantics, to make sure I indent and define the objects properly. I don’t have sophisticated IDEs (like what I would get with application programming languages) to validate the syntax or semantics

Learning a new language: Terraform is a DSL (domain-specific language) and requires significant effort to learn and master.

How would it be, if I don’t have to learn any new language, use the existing IDEs and still write IaC…that is a dream come true for a full stack developer like me. And that is where I was super impressed with what Pulumi had to offer. It provides a framework for me to build Infrastructure code in any of the popular languages, that I already know!

To get a deeper understanding of this amazing tool. I am writing this series of blogs. In this “Platform Engineering with Pulumi” blog series, I will be building a landing zone on AWS to deploy my Node.js application and automate the deployments with GitOps. The series has these 3 blogs:

Episode 1: Building the AWS Landing Zone with Pulumi (current blog): In this blog, I will cover some key concepts and architecture of Pulumi. We will be building and provisioning the landing zone.
Episode 2: Building and Deploying the nodejs application: In this episode we will be building a simple ContactList application in nodejs/HTML and deploying it on the EC2 instance and store all the contacts in DynamoDB
Episode 3: Platform & Application deployment with GitOps automation: In this episode we will be automating the inftrastructure and application code deployment and changes using GitOps principles. We will be using GitHub Actions to continously deploy infrastrcture code and using AWS CodeDeploy to deploy application code

In this blog series, we will be building the following infrastructure on AWS and will run our applications in the EC2 instance. You guys might be wondering why EC2? If I were to do this, I would have done it on ECS/OpenShift/K8s, which is more modern. But then, there is no challenge. I selected this (legacy) architecture, to explore more concepts, so bear with me :-D and play along

Step 1: Install Pulumi

I am using macOS, it's very convenient for me to install using the following command. Please refer to the Pulumi documentation for instructions to install Pulumi for your target OS.

brew install pulumi

Step 2: Setup AWS CLI

Please refer to the AWS documentation to install and set up. In my case, I had already installed the CLI, created a credential on AWS IAM, and used aws configureto configure the CLI with the API key and secret access key, that I created in IAM.

We also need to export 2 environment variables, so that Pulumi can use them to log in to our AWS account.

export AWS_ACCESS_KEY_ID= && export AWS_SECRET_ACCESS_KEY=

Now we have aws CLI and Pulumi CLI ready to connect to our aws account. Let's now start writing some infrastructure code.

Step 3: Generate Pulumi project — boilerplate code for AWS in Python

Python?? yes that's the best part about Pulumi, I can write my infrastructure code in my desired language. Pulumi supports the following languages when I was writing this blog for AWS.

To generate the boilerplate code for AWS in Python language run the following command:

pulumi new aws-python

This will prompt us to log in to Pulumi, I used my GitHub as a sign-in. Once login is successful the Pulumi CLI generates the boilerplate code.

The following screenshot shows the generated files. Let's understand what is generated:

venv: is the Python virtual environment, which will help us work in a sandbox, as we install all the dependencies.
main.py: This is the main python code file, where we will be writing the code
Pulumi.yaml: This file has the project metadata, that we have provided while generating the boilerplate.
Pulumi.dev.yaml: This file has the configuration values for the stack, we can define different environments as stacks.
requirements.txt: This has all the python dependencies. we will be installing all the dependencies in the next step

Let's understand Pulumi architecture. The following picture shows a high-level architecture of Pulumi:

Project: Pulumi project is a collection of the files, of a module. Each project has a Pulumi.yaml file which has the project configuration. a new project can be created using Pulumi new command. Refer to Pulumi documentation for more details.
Program: Program is the actual infrastructure code, This is written in high-level languages such as python, javascript, etc.
Stack: Stack is a very important concept. This allows us to define various configurations for each environment and allows us to deploy and manage individual environments. typically we would have dev, test, prod environments. For each stack, we will have a Pulumi..yaml file. Refer to Pulumi documentation for more details
CLI: Pulumi CLI provides a command-line interface to build, run and manage the Pulumi runtime/deployment engine.
State: State is a very important component of the architecture, which stores the current state of the infrastructure, and makes sure, the configuration is synced up with the actual infrastructure on the cloud. By default the state is stored in the Pulumi backend, however, we can configure some other object storage (such as S3) to store the state. Please refer to Pulumi documentation for more details.
Hyperscaler integration: Pulimi internally uses hyperscaler APIs or Terraform modules to provision and manage the infrastructure.

Step 4: Activate virtual environment and install dependencies

Let's activate the venv using:

source ./venv/bin/activate

And install the dependencies with the following command:

pip3 install -r requirements.txt

You will see a bunch of dependencies installed in the Python environment. Now we are ready to write some infra code.

Step 5: Set up public/private key infra

When we provision EC2 instance, we will need a public/private key infrastructure to be programmatically created (if we had created the instance from the AWS console, we would have downloaded it manually.) Since we are automating the provisioning, we will create our public/private keys, and configure the EC2 to use our created key-pair

ssh-keygen -t rsa -f rsa -b 4096 -m PEM

This command creates rsa, rsa.pub

Step 6: Write Infra code

Here is the complete code, in snippets and explanation:

Line 1–7: import the dependent modules

pulumi is the core module.
pulumi_aws module has the aws objects, that we will be using.
provisioners module is an implementation of Terraform provisioner in Pulumi, which allows us to copy files, run commands remotely on the EC2 instance. Refer to documentation.
base64 has the library to encode and decode base64.
json module is required to serialize json configurations.

Line #9–13: We are initializing the config object, and retrieving the configuration from the Pulumi.dev.yaml file, where we have set the key name and public key. To create this secret configuration, we can use

pulumi config set --secret privateKey

pulumi config set --secret privateKeyPassphrase

the publicKey is not a secret is a direct copy-paste from the public key

Here is a screenshot:

Line #15–25: helper function to encode base64

Line #27-28: getting the secret configs from the respective Pulumi stack config file (since we are running in dev stack, it will read from Pulumi.dev.yaml)

Line #31–33: We are creating a keypair with our keys on AWS. Here is a screenshot after we run this code.

Now let's set up the VPC:

Line #37–66: In the above code, we are creating the VPC and an internet gateway. We are then creating the public subnet, in which we will be running the EC2 instance. We also need a route to the internet gateway, to access the public internet.

Line #69–95: We are creating a security group with 2 ingresses (One on port 80 to access the website, that we are going to build, and one on port 22, to SSH to the EC2 instance) and 1 egress for the EC2 instance to access the internet.

Line #98–124: We are creating a DynamoDB table with 2 fields — ContactName and ContactNumber.

Line #133–136: We are creating a VPC endpoint, to access this DynamoDB directly from the VPC, let's create a VPC endpoint (instead of going through the public internet).

Line #143–158: We are creating an EC2role that we will need when we set up the GitOps to deploy the applications using CodeDeploy (which I will be covering in my next blog).

Line #160–165: We are looking up the right AMI, using a filter.

Line #167–182: We are providing the user data to set up the EC2 instance when we start it for the first time, which does the typical yum update, installs cURL, Node.js, Yarn, Ruby, CodeDeploy (which we will need to deploy the applications using GitOps, I will be covering this in the next blog).

Line #183: We are creating an IAM instance profile and connecting that to the EC2role that we created, which we will need when we do the Code Deploy.

Line #184–195: We are creating an instance of the AMI, that we looked up, and creating a t2.micro instance, and passing the user data, IAM instance profile, public subnet, and the security group we created. We are also passing the keypair that we created so that we can connect to this EC2 instance using the key pair that we created.

Lets now run this code, and see the output, by running pulumi up

The following screenshot shows Pulumi comparing the state and providing the status of what resources will be created. I will discuss state management in a separate blog.

Once, we verify, we can access it to go ahead. The following screenshot shows the output of all the resources created.

Let's now connect to the EC2 instance and check by running:

ssh -i rsa ec2-user@3.239.26.182

Now that we have created the landing zone successfully using Pulumi, let's build and deployNode.js application and run it. Since it's already a long blog…we will continue in Episode 2.

Hope this was helpful, let's meet in the next blog…until then stay safe, and have fun, take care.

You can access the complete source code in my GitHub here.

References: