Forem: Shweta Vohra

Service Mesh and Enterprise Scale Design

Shweta Vohra — Fri, 06 Jan 2023 03:23:34 +0000

Service mesh is a low latency networking and infrastructure layer which is highly configurable to make service-to-service communication possible.

In this article let's look at following aspects for Service Mesh:

Introduction, features and architecture
Enterprise level service mesh - What and why?
Approach for - enterprise level service mesh implementation
An enterprise - case study

Services Interaction without useing Service Mesh:

There were many technology specific libraries/tools in use to make above complex interactions possible. For example:
Python:

OpenTracing Flask
OpenCensus
Zipkin
Kingpin
Lemur

Java:

Spring
OpenTracing
OpenSSL
Customer libraries

Nodejs

Jaegar
Zoologist
Express RL

Its quite evident the problem of handling polyglot libraries, discovery of services, specific use of tools and most importantly lack of easy interoperability of these solutions makes maintianing services life cycle a mammoth task.
Now let's look at how Service Mesh helps save these efforts.

Services Interaction after using service mesh:

Service Mesh Features

Service Mesh Architecture

A service mesh comprises of two main logical components - a data plane and a control plane:

The data plane is composed of a set of intelligent proxies deployed as sidecars. These proxies mediate and control all network communication between microservices. They also collect and report telemetry on all mesh traffic.
The control plane manages and configures the proxies to route traffic.

Service Mesh At Enterprise Scale

In practical there are complex environments. Heterogenous cloud, application stacks, and platforms. Service mesh required for strong deployment and control over Dev and Ops across hybrid cloud environment.

For example consider application spread across various clusters in hybrid cloud environment such as one shown in diagram below:

  ## `How would you plan such type of complex service mesh?`

Let's make it little more complicated with real case study

Use Case from Telecom Domain

In order to design such kind of complex service mesh you need systematic framework to decide and plan for your service mesh architecture, features and implementation.
We will look at details in the upcoming article. Watch this space for more.

AWS Landing Zone and Control Tower

Shweta Vohra — Fri, 06 Jan 2023 01:12:36 +0000

Client is looking to get into AWS for the first time, they may know a bit about platform architecture such as Regions, Availability Zones, EC2, S3, VPN's etc. But they may not know that there is a whole other space around procurement, billing, and AWS accounts, organization and sub organization structure, network, security infrastructure and many more things that needs to be considered as part of any enterprise-grade setup, especially at scale. That’s where you need Landing Zone.

Landing zone can provide following things:

A landing zone is a well-architected, multi-account AWS environment that’s based on security and compliance best practices
It provides a baseline to get started with multi-account architecture
Fundamental aspects for any complex hybrid cloud such as access control, governance, data security, network design, and shared services such as logging/ monitoring etc.
Automating and setting up cloud using AWS control tower for faster pace and repeatability
Setting up right set of policies and compliances for the your Industry

Landing Zone Benefits

The Landing Zone solution provides users with a few key benefits designed to allow easy control of multiple accounts. Here’s a quick overview of all the benefits you can expect:

Automatic AWS environment setup
Saves a lot of time and effort
AVM or Account Vending Machine
Managing multiple accounts
Automatic baseline security feature setup
Account management
Centralized logging
The setup is done according to the best practices
Efficient governance and operation
Creates a flexible business environment

How to create Landing Zone?

When we start thinking about AWS and what customers want to do on AWS, we need to first think about requirements to better understand what the customers need. For example:

Which is the right service/tool to use?
What about security, governance, and baseline?
How many accounts should I create for my customer based on use cases?
How many users, groups, and what permissions should they have?

Let me also introduce you to the concept of a Landing Zone and Control Tower with respect to when they work well together.

AWS Landing Zone vs. Control Tower

AWS Control Tower is an AWS managed service able to control all the resources that are part of: AWS Organizations, Identity and Access Management, Guardrails, Service Catalog and multi AWS accounts. Through the Service Catalog, you can create as many accounts as you want and apply to them the rules based on the requirements. Control Tower sets up a Landing zone in easy and secure way.
vs.
Landing Zone is a solution provided by AWS Control Tower or you can create your own solution based on your requirements. Your own CloudFormation or Terraform stacks across AWS accounts.

Both Control Tower and Landing Zone help set up and manage secure multi-account AWS environments. Now the question comes which one should customers use? Let's take a closer look and figure out.

Three different ways to create landing zones are:

A landing zone based on services using AWS Control Tower
A CloudFormation solution build within the AWS Landing Zone
A Custom landing zone you build manually

More details in upcoming article. Watch this space for more.

Must know — Container Security Constructs: Namespace, SecComp, Control Groups, SELinux

Shweta Vohra — Thu, 05 Jan 2023 17:12:49 +0000

SELinux

SELinux (Security-Enhanced Linux) is a mandatory access control system for processes. Linux kernel uses SELinux to protect processes from each other and to protect the host system from its running processes. Processes run as a confined SELinux type that has limited access to host system resources.

Condition that brings SELINUX into action. Check or configure file /etc/selinux/config for possible SELINUX values:

SELINUX=disabled or
SELINUX=enforcing or
SELINUX=permissive

Seccomp

Seccomp stands for secure computing mode.

The seccomp() system call operates on the Secure Computing
(seccomp) state of the calling process.
*Man page definition

Seccomp limits how processes could use system calls. Seccomp defines a security profile for processes, whitelisting the system calls, parameters and file descriptors they are allowed to use. SecComp defines which system calls should and should not be allowed to be executed by a container. It restricts the calls a process/continer able to make from userspace into the kernel.

Namespaces

The kernel can isolate specific system resources, usually visible to all processes. This is done by placing the resources within a namespace. Inside a namespace, only processes that are members of that namespace can see or utilize those resources. Namespces help apply security restrictions to containers. Below mentioned are major 7 namespaces that help achieve boundaries and restrictions:

Cgroup — Cgroup root directory
IPC — Inter Process Communication, POSIX message queues
Network — Network devices, stacks, ports, etc.
Mount — Mount points
PID — Process IDs
User — User and group IDs
UTS — Hostname and NIS domain name

Control groups (cgroups)

Control groups partition sets of processes and their children into groups to manage and limit the resources they consume. Control groups place restrictions on the amount of system resources that processes can use. Those restrictions keep one process/container from using too many resources on the host.

CGroups Examples:
— cpu-shares
— cpuset-cpus
— memory-reservation
— kernel-memory
— blkio-weight (block IO)
— device-read-iops
— device-write-iops

For more information on this topic listen recorded session here.

Thankfully AWS EKS and other AWS container services are security hardened and therefore cannot be mis-used by essential container constructs.

EFS vs. FSx for ONTAP

Shweta Vohra — Sun, 19 Jun 2022 17:08:45 +0000

EFS vs. FSx for ONTAP - I did this comparison for some client scenario recently and found some interesting attributes where these two services have their own merits and distinctions. Hope you find this useful!

Amazon EFS lock limits are recently increased. Do read here for more details:
EFS Lock Limits News

How to conduct AWS WAF review efficiently?

Shweta Vohra — Sun, 29 May 2022 14:00:00 +0000

Authors: Shweta Vohra, Siddhartha Sood, Balakrishnan Sreenivasan

With experience utilizing WAF reviews, we have built the systematic guidance and checklist based on our own experiences to help teams undergoing Well Architected Framework Reviews. This is starting point for Reviewers, Architects and Developers to plan for AWS WAF Review.

Pre-requisites For Review

To use this framework efficiently there is preparation required for each of the six fundamental pillars. In case you are new to AWS WAF Review then What is AWS WAF?. The team or individual architect performing this well architected review should be thorough and qualified in following aspects:

First and foremost - Reviewer must be an "AWS Solution Architect - Professional Certified" and even better if person is "AWS WAF Certified Reviewer" for well architected framework (Check AWS Well-Architected Partner Bootcamp if you have access). In any case reviewer should be well versed with all assistive AWS services and tool.
One should know all six pillars and should have read whitepapers as mentioned below. This is by far the most comprehensive yet best guidance about these pillars:

Get accustomed with Well architected framework Tool through AWS Console. Reviewer should know the tool and its features, and different reports that it can produce. One should also complete AWS well architected comprehensive Labs to get acquainted to various aspects linked with each pillar.
Define the workload or in other words logical group of resources that needs to be reviewed. It can be one application, resources in one account or vpc, group of accounts or any other organization centric criteria. Additionally, Reviewer also need to know the organization, requirements and prioritize in advance workload for which review needs to be conducted.
Bring all required stakeholders together for efficient review. These should be representative/s who can support all facets of organization such as developer, architects, governance, operational, Security, business, and strategy.
Involve domain or industry specialist if AWS Well Architected Industry specific lens review required. Refer section on Industry lenses for more details.

Review Tool and Guidance

Steps to Follow:

Open AWS WAF Tool -> Open your AWS account and navigate to space (Region, VPC, Workload etc.) where review needs to be performed for upcoming or already present workload/Software.
Search -> "AWS Well-Architected Tool" on AWS console
Define-> workload on same AWS account, different account, or upcoming design
Document the Workload State -> Review an architecture by answering a set of Questions. Choose answers grouped into Six Pillars. Review screen on AWS console looks like as specified in below image for your reference.
Review the Improvement Plan after review completion &
Make Improvements and Measure Progress

Example Process Involved:
Below table gives high level guidance on operational excellence pillar (as an example) for how to systematically prepare for each pillar review during AWS Well Architected Framework Review:

As mentioned in above table, reviewer should prepare customized review guidelines, processes and services that are applicable to workload and client organization for which review is being planned.

After Review - Outcomes, Reports and Plan

Review report gives outcomes in form of two types of Risk items:

High Risks Items (HRIs) and Medium Risk Items (MRIs)

Tool also provides prioritized improvement plan for each prioritized pillars based on high-risk items. Reviewer should help client priortize the High and Medium Risk items to incorporate in their AWS Cloud, services and applications. Both reviewer and reviewee team (client) should agree on creating further milestone reviews. This helps in continuous evolving workloads and ensuring that review feedback is incorporated.
For example, milestones can be design time, pre Go-Live, version 1 release, new feature release, architecture board continuous reviews etc. On AWS tool sample milestones appear as given below in snapshot:

Post Review - Evolve

Architecture on cloud is not one time activity. Therefore, reviewer should be reviewing workloads with continuous milestones and frequent reviews as per frequency decided mutually with client. Ideally it should be done every quarter so to overcome all high and medium risks associated with reviewed workload and enforcing best practices to the maximum. However timelines should be adopted as per client and reviewers mutual agreement.

Watch out for articles:
Specific Example Guidance - Will be added soon!

AWS Well Architecture Framework - Review Guidance, Tool Usage and Trainings

Shweta Vohra — Sun, 29 May 2022 13:44:00 +0000

Authors: Shweta Vohra, Siddhartha Sood, Balakrishnan Sreenivasan

A. Document Scope

This document gives AWS Well Architected Framework (WAF) introduction and subsequent linked articles for utilizing this framework efficiently.
Not trying to replicate vast information and documentation available for AWS WAF framework. However, this document serves as the Introduction as well as guidance for new or experienced architects to conduct Well architechted reviews efficiently and continuously.

B. Introduction - AWS WAF

Cloud based systems and solutions brings agility for organizations. With agility comes continuous changes and evolution of business capability and architecture maturity. As architecture is not one time activity on cloud and at the same time does include decisions and trade-offs that best represent the architected system and can still evolve. Therefore, AWS provides this guidance, tool & APIs in form of AWS Well Architected Framework. This framework provides a highly stable and consistent approach for customers and partners to evaluate architectures and provides prescriptive guidance to help implement designs that are scalable, secure, performant, reliable, sustainable, and optimized. Popular AWS Well Architected Framework is practical step by step guidance from AWS for creation, review, and continuous assessment of cloud-based workloads/ software

The AWS Well-Architected Framework is based on six pillars as mentioned below:

Operational Excellence - Infrastructure and other resources efficient operationalization. This includes IaC (Infrastructure as Code), monitoring, and ease of continuous use.
Security - This pillar ensures guidance in form of areas where security should be investigated and how to seal it wholistically
Reliability - Differentiating on cloud by proactively building and designing reliable systems with reliable components and services so that resources are always available, can scale as per demand and resilient. This pillar guides on this aspect
Performance Efficiency - This pillar guides on computing requirements and how to efficiently utilize them
Cost Optimization - Guidance on how to continuously benefit from cloud services still get optimal price point
Sustainability - This newly introduced pillar has been announced in 2021 AWS Re:Invent to take care of long term environmental impacts, especially energy consumption and resources efficiency

For all above pillars this framework defines following:
- Design Principles- These principles give basic sense and fundamental coverage around each of the pillars
- Best Practices - Best practices provides pillar wise questionnaire and supporting ideal state for the best practice to support and gauge the current state of client workload and
- Resources - Additional resources for each pillar to get in-depth information based on relevant domain and work area

C. How to use this framework efficiently for review?

With experience utilizing WAF reviews, we have built the systematic guidance and checklist based on our own experiences to help teams undergoing Well Architected Framework Reviews. Check out this article to know more: How to conduct AWS WAF reviews efficiently?

D. AWS Well-Architected Lenses

AWS is in process of enhancing the Well Architected Framework. As part of enhancements AWS is releasing domain specific or technology centric WAF guidance. For example for IOT type of workload there is IOT Lens, for serverless kind of workloads where resources are primarily running on a serverless approach/design there is serverless lens.
Lenses provide a way to consistently measure architectures against best practices in that domain or technology and identify areas for improvement. The AWS Well-Architected Framework Lens is automatically applied when a workload is defined in addition to additional lens that you might have included at the time of review on tool. A workload can have one or more lenses applied. Each lens has its own set of questions, best practices, notes, and improvement plan. Based on selection and applicability of review resources, reviewer should refer lens specific checklist that are available as part of documentation and mentioned in Appendix section of this document.

At the time of writing of this document 3 lenses have been integrated on tool. Please refer below image for lenses that are integrated with AWS Well Architected Tool.

E. AWS WAF Training Path

To gain insights into AWS WAF process as reviewer you can attend following trainings and follow path to become AWS Certified WAF Reviewer:

Well Architect Proficient Badge
Class-Room Trainings (Available to AWS Patner Connects):

AWS Partner: Well-Architected Best Practices
AWS Partner: Advanced AWS Well-Architected Best Practices

F. Appendix - Links and References

Must know — Container Security Constructs: Namespace, SecComp, Control Groups, SELinux

Shweta Vohra — Wed, 25 May 2022 06:14:31 +0000

SELinux

Condition that brings SELINUX into action. Check or configure file /etc/selinux/config for possible SELINUX values:

SELINUX=disabled or
SELINUX=enforcing or
SELINUX=permissive

Seccomp

Seccomp stands for secure computing mode.

The seccomp() system call operates on the Secure Computing (seccomp) state of the calling process.

*Man page definition

Namespaces

Cgroup — Cgroup root directory
IPC — Inter Process Communication, POSIX message queues
Network — Network devices, stacks, ports, etc.
Mount — Mount points
PID — Process IDs
User — User and group IDs
UTS — Hostname and NIS domain name

Control groups (cgroups)

CGroups Options(Examples):

— cpu-shares
— cpuset-cpus
— memory-reservation
— kernel-memory
— blkio-weight (block IO)
— device-read-iops
— device-write-iops

Is Kubernetes- Boring or Boon?

Shweta Vohra — Mon, 06 Dec 2021 10:08:42 +0000

Is Kubernetes boring, tedious or boon? I have heard both sides of arguments in favour and many a times not so much in favour of K8S. Kubernetes is a popular technology these days. Every IT company is promoting it, end users/customers either using it or talking about it or evolving with it, Open-source users and contributors love it and there are so many jobs in market that require this skill set (both JD and package wise 😉). Certainly, there is time to check what is clicking and what is not?
This article presents an independent view and reality check on what makes Kubernetes tick and what it is failing to give?
Read on and please do share your constructive views/likes/comments.

Let's first understand few basics and background to set the context right:

What is Kubernetes?

In simplest words it is Container Orchestration Platform. This technology is created to take care of containers lifecycle management with ease and for maximum containerization benefits.
It was an internal project developed and used by Google initially and then donated the project to The Cloud Native Computing Foundation (CNCF) at the time of CNCF inception. Since Kubernetes adopted by CNCF this has grown in leaps and bounds and still growing with loads of contributions from open-source community. There are many managed Kubernetes services/ platform flavours that have been laid out on top of native Kubernetes by companies like Red Hat, IBM, Google, AWS, Azure, VMWare and many more.

CNCF Philosophy - Maintainer of Kubernetes

CNCF is always working on adoption of various cloud native technology paradigm by fostering and sustaining an ecosystem of open-source in most vendor-neutral way. Their philosophy is to democratize the technology patterns to make those innovations accessible for everyone. This also includes Kubernetes which is one of the most popular and already graduated projects of CNCF. We also need to note, as per CNCF charter, they value fast is better than slow, open code, conduct and technology, fair, strong technical identity, clear boundaries, scalable, platform agnostic.

Picture source: Released by CNCF in 2020

Now given this background let's evaluate this technology based on two major criterias:

Adoption vs. Ease of Adoption

How far this technology actually adopted by organizations, techies and how easy it is to use and adopt by business. Both these parameters are important to understand for successful adoption of any technology and so is true for Kubernetes.

What makes it Popular?

Open-Source Superpower - Kubernetes being CNCF maintained project it has got super power of development and nurturing by open-source community which means best of all open minds shaping the future in very systematic way.
Most Vendor Neutral Technology- Due to Open-source power this technology is not locked and blocked by any vendor or cloud provider. There is no dependencies on any specific people or organizations. All can use it and shape it up further. In fact features like operator framework makes it possible to add customized functionalities to the Kubernetes and help extend it faster.
Pace of Innovation - Kubernetes and relative set of technologies are keeping everyone on their toes be it individuals, organizations, and end users by the way of number of super charged advancements and releases that CNCF gives.
End User Beneficial - Important aspect of Kubernetes is that it weaves many things together that promote cloud adoption and cloud native applications and therefore helping end user to innovate for new challenging situations and provide more and more tools to use by developers and Operations as well as exceptional benefits to their customers.

What makes it difficult and tedious?

Designing and implementing a production grade application - To reap benefits of K8S one needs to put lot of efforts in collating all required application life cycle elements such as application sizing, converting them to containers, storing them to registry, using proper services communication or mesh, observability, version management, deploying security solutions, setting up access, continuous integration, performance etc. All this and much more needs to be taken care before application starts reaping benefits of Kubernetes features and be production ready.
Architectural complexity -Kubernetes architecture comes with few mandatory components that are provided for working of Kubernetes cluster and container orchestration features. Rest all features gets bundled either through other CNCF projects or Vendor services. There are also standards and interfaces that kubernetes provides such container runtime interface (CRI), container networking interface (CNI), container storage interface (CSI), Infrastructure options, container engines options (docker, CRI-O, RKT etc.), service mesh options (Istio, Linkerd, AWS AppMesh etc.) and many more. These choices come with burden of selection, installation and maintaining such custom cluster configuration. This all makes bringing up and maintaining a "Well Architected Kubernetes Ready Platform" complex.
Hard for Developers and SysOps -Due to all above reasons it's hard for developers, it lacks the development agility and takes long ramp-up curve to understand and utilize it in entirety. Not just for developers even administrators or Ops need to know lot of things to maintain such a cluster and its run time issues with CLI tools such as kubectl, etcdctl, systemctl, YAML/JSON, helm charts and what not?

Based on above let's summarise for Adoption vs. Ease of Adoption. Its clear that adoption is tough due to continuous evolution and variety of options to choose from that comes with Kubernetes. Even though there are products like RedHat OpenShift in market that have overcome many shortcomings by bundling developer centric platforms with packaging of services that makes it complete. However, such options do come with cost involved and licensing etc. So, the big question is Simplification of Native Kubernetes: Shall we attempt or not? - When I asked this question about simplification during a panel discussion to CNCF stalwarts during one of the KubeCon. The answer I got, "Its left to managed service providers to address the gaps (as areas mentioned above in pros and cons)".

In my view (independent view) we need to balance between Adoption and Ease of Adoption

Adoption:
a) Organizations need to catch up fast on adopting the new and creating their eco-system that is agile and learning/ improving continuously. There is no two ways about the same. b) There was a time when similar kind of critiquing and confusion was around Linux (Linux vs. Windows days). Linux was not easy. It had multiple flavours, CLI, open-source contributions, less of developer centricity and mostly similar questions and doubts as we have today with Kubernetes. However, we all know what is Linux today and still advancing in technology and strengthening year on year. While both popular OS exists today that is linux as well as windows. We are widely using Linux everywhere and windows has learnt to be compatible with Linux in so many ways c) Hence instead of missing the wave of Kubernetes, its favourable learning/leveraging it in whatever capacity individuals or organizations can do that.

Ease of Adoption:
While we understand companies/individuals need to learn and constantly adapt. But.. a) There are many business problems that take priority rather than every company turns into an IT company (in a way it's happening already 😉). b) On other hand as there is great emphasis on reducing carbon footprint by CNCF and many open-source contributors. Imagine how much efforts and resources would be saved across platforms, cloud providers, customers, developers, administrators - if Kubernetes bundling and maintenance is simplified. c) This is an area that should be relooked into by CNCF to make the native kubernetes releases to be adopted faster, updated with ease and for faster application setup/development management. Focus should be there to simplifying Kubernetes packaging and architecture. There can be complete bundling for all required application lifecycle features (minimal bundle/s) to choose from while taking care of container lifecycle features. Therefore, even if Kubernetes is mature or maturing further, it would be great to see CNCF addressing these aspect for everyone.