DEV Community: Run [X]

K8s Pods: Image tags vs. Digest

Nočnica Mellifera — Wed, 27 Oct 2021 17:41:03 +0000

Image tags are a common source of frustration with the management of Kubernetes pods. How many times have I seen a question like this

I am unable to see my changes, even though I am using the referencing the image using the Correct Tag.

Or even worse:

I haven't changed the Referenced for the Image, but its behavior changed

These are normal problems to face do the basic design of Docker's image management.

But before diving in, let's see thee terminology that we'll be talking about.

Image Tag

Human understandable reference to an Image used to convey information about that variant. An image can be tagged with multiple tags and can be referenced using any.

Properties:

Mutable
Unique (i.e., the same tag can be used on multiple Images and will reference the last image that was tagged)

Image Digest

Hash reference to an Image.

Properties:

Immutable
Created when pushing an Image to the Repository for the first time.

General Practice

Programmers tend to reference the Images using the Image tags, for the obvious reason of getting a better readability, but in doing so, an important blind spot is missed: an image I1 referenced at time T1, may refer to image I2 at time T2.

This generally happens when the Programmer is referring to generic tags such as latest, or can happen due to Human error, when you end up tagging Image with an already used Tag.

Use Cases

Using latest to point to latest version always. Some other self-explanatory tags like qa / dev / prod, versioning tags like x.y.x for maintaining versions.

Non-deterministic Deployment

When using Image tags for referencing the Image, there is no guarantee that the Tag would refer to the expected Image, because of Tag Mutability.

Another defect with the non-deterministic deployment is some infrastructure tools which are dependent on the Stage Changes, will not be able to detect the changes when using generic tags and no versioning, or if due to a human error of mutating the tags.

In order to avoid Non-Deterministic deployment, we should use Immutable Image Identifier Image Digest should be used. But this way, we lose the Human readability. In order to have Human Readability, as well as Deterministic Deployment, we can refer to the Image using both Image Tag and Image Digest. Docker gives us the capability to integrate both and refer to the Image.

Image Reference: <image_name>:<image_tag>@<image_digest>

Deployment Image with Tag vs Digest

Different ways of referencing

Accessing a resource from a collection of similar resources is always easy when there is a versioning attached to it. It helps users to have a better control the specific resource that they are using. This is useful when versioning attached to the resources is immutable. But at times, situations arise where one wants to have even more readability, for ex., using the latest version ever of the resource every time or raising a small patch so that it reflects in the version. In such cases, we would require the tags to be mutable.

This is the usability around which the K8s Pods were build. Having mutable tags gives the ability to have named versions, something which makes a lot of sense because things are kept easier on the pipelines, like take the latest image, use the dev image, or maybe when a fix is so small that it doesn’t require a version update.

So, now that the versions, a.k.a., tags, are mutable. So, does that mean that is nothing immutable that can be used to get the same Image again and again. This is where the Digest comes into the picture. This is a hash key that is created based on what all base images are used for constructing the image and this is unique for every different image. Digest can be used to reference the same image again and again.

Now let’s get into some techie stuff

Why are tags important?

Tags are human understandable reference to an Image used to convey information about that variant. An image can be tagged with multiple tags and can be referenced using any. Importantly, a tag can be changed to different images.

What is Non-deterministic Deployment?

When using Image tags for referencing the Image, there is no guarantee that the Tag would refer to the expected Image, because of Tag Mutability.

This drawback is for the Infrastructure Tools, which depend on State Changes, as the tools will not be able to find the difference in the state, if the Tag refers to a different image or not.

So, how do we make this deterministic?

In order to get the best of both the worlds, that is human understandable reference as well as deterministic deployments, there needs to be a Dynamic Mapping between Image Tag and Image Digest which can be used when deploying images. While pushing to a repository, we can tag the image and then once the digest is created, use that to deploy the images.

How can OPTA help?

What is Opta?

Opta is a platform for running containerised workloads in the cloud. It abstracts away the complexity of networking, IAM, K8s, and various other components - giving you a clean cloud agnostic interface to deploy and run your containers. It’s all configuration driven so you always get a repeatable copy of your infrastructure.

How does Opta help?

Deploy option of Opta with an image tag input would automatically create the Dynamic Mapping between the Image uploaded to the Repository and use the Image digest to deploy the Image.

For more information on how to use Opta, use this: https://docs.opta.dev/getting-started/

[Video] Running your cloud locally: Opta's Open source Infrastructure as Code

Nočnica Mellifera — Mon, 11 Oct 2021 18:56:15 +0000

Opta is a way to get started deploying services in the cloud without having to understand the nitty-gritty of permissions and connection settings between components.

In this quick video, Sachin demonstrates how you can run Opta locally before you deploy to AWS.

The goal with Opta Local is to let you preview how your application code is running from your laptop without having to deploy to the cloud for every code change

Can we build a better Terraform? The story of Opta

Nočnica Mellifera — Wed, 29 Sep 2021 12:39:12 +0000

cover image by By Daein Ballard - CC BY-SA 3.0
Managing to distributed systems is... difficult. You can find guides and recommendations everywhere that say if you don't have to do a distributed workload you shouldn't.

An article from last year by yours truly argued that containers and container orchestration have very different futures: It makes sense that almost everyone will be working with containers in the future, but it's not as clear that container orchestration knowledge will be de rigueur.

// Detect dark theme var iframe = document.getElementById('tweet-1358307866961084422-274'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1358307866961084422&theme=dark" }

As we've faced this complexity of modern distributed workloads a number of companies have tried to make this work easier. These tools tend to fall into three categories:

"We have an okay tool, but hire us and we'll deliver your whole cloud"

When tools are sold with strict SLA's and mandatory professional services, you're often really purchasing Kubernetes expertise rather than great software

"Our Tool is Free! (for 90 days)"

Often a partially-open-source-tool that inevitably requires some Software-as-a-Service component to really work, a number of tools will lock you into their platform, never give you all the tools, and rarely offer you any support if things go wrong

Actual Open Source

These are teams releasing tools as Open Source Software that can be used, start to finish, on your own. Multiple teams see the growth potential in Kubernetes and other distributed workloads and just want to grow with the industry. They offer professional services or hosted servers in addition to free tools, but you can do the whole thing start to finish yourself.

While this third option sounds a lot better for the user, it can still hit pitfalls. The industry standard Terraform is currently struggling to keep up with community PRs and is in danger of falling behind users needs.

This isn't a new story: Large-ish companies can struggle to justify the cost of maintaining an open source tool, and once they grow to that medium size it's hard to find the time to maintain a tool everyone wants but no one has time to update.

Trying to build a better Terraform

Enter RunX, a small team focused on trying to build a fully modern tool for deploying distributed workloads. We're a small team of just 8, laser focused on reducing toil for cloud engineers. We just raised 4 million in funding, and we'd love you to try out Opta, the easier way to deploy.

Can Kubernetes Save You Money?

Nočnica Mellifera — Fri, 24 Sep 2021 16:52:49 +0000

cover image: detail from Hieronymus Bosch - Death and the Miser

Kubernetes is not known as a particularly economic option. If you're migrating to a distributed architecture from a simple virtual machine, you're likely to see an increase in hosting costs and hours spent on setup at first.

A recent article on our RunX blog talked about how you can save money using Opta to deploy the same project to AWS you previously would have hosted on Heroku.

I'm curious if you've seen overall cost savings by switching to Kubernetes, either from an older distributed compute tool or a monolithic architecture.

Tesla Bot is a great example of how NOT to develop a product

Nočnica Mellifera — Wed, 22 Sep 2021 19:02:16 +0000

Image by u/Kruzat, available via Creative Commons Attribution-ShareAlike 4.0 International License

As I’m sure many of you have already seen, Elon Musk has announced Tesla Bot, a humanoid robot intended to“automate repetitive tasks”. The CEO announced Tesla Bot not with a working prototype or even a partial proof-of-concept, but with a dancer dressed in a modified morphe suit who “gyrated wildly on stage” before the presentation. The robot has a vague timetable, with Musk claiming a prototype will be out sometime next year, and an ambitious set of (at this point hypothetical) specifications: the ability to not only understand and interpret voice commands, but carry out tasks ranging from factory assembly to grocery shopping. Musk has announced that a universal basic income will be necessary to support the people unemployed by his imagined product.

While claims of this magnitude are pretty rare, the bones of the scenario are pretty universal: the boss overpromises on a product that the actual development team knows will be impossible to roll out by the deadline. So what do you do when your boss overcommits your team to building, say, a fully-autonomous robot that can work at Amazon in one year?

Allison Green of Ask A Manager has advice for pushing back on a boss’s decision. “A good boss does want to know when you disagree with something, especially if you feel strongly and especially if you have information or context she might not have considered,” Green says. She says to consider whether you have information that your boss doesn’t have that might make them reconsider, or when a course of action might have consequences that your boss isn’t aware of yet. Executive coach Daneen Skube also says that you can put the onus on your boss to give you the roadmap to achieving what they’ve come up with. “Don’t let your boss get away with platitudes and grand concepts,” she says. “Keep looking confused as you query him about how to implement his noble goals.”

Green and Skube agree that if your boss decides to keep overpromising, your chances of dissuading them are limited, and you should consider the importance of the issue to you. If you work at a company, for example, that has a history of pushing nonviable products, within that company culture it might not be possible as an individual to “manage up” by correcting your boss--especially if your boss is known to take criticism poorly. An individual who continues to vocally disagree after the boss has shut that disagreement down could come across as hostile, even if their concerns are valid and serious.

When a boss is unlikely to respond well to one person pushing back, another choice is to push back as a group. Green has specific suggestions for how to handle that. She says the important thing is to make sure that you and the rest of your group are on the same page about it, and to address the boss together, rather than appointing a spokesperson. It’s also worth remembering that a particularly self-aggrandizing or hostile boss might try to divide and conquer--it might be worth practicing the conversation beforehand, with one of your coworkers playing the boss.

And finally: if your company routinely overpromises and fails publicly, it might be worth looking for a new job. No amount of prestige is worth the headache of having a boss who chronically oversells and then makes it your problem when the product can’t live up to the hype.

Embrace Remote Work or Perish

Nočnica Mellifera — Thu, 16 Sep 2021 13:34:03 +0000

cover image by Matt.c.28 - Own work, CC BY-SA 4.0

Recently our team at RunX was featured in a piece on remote work that has proven something of a rorschach test: in comments on the article and social media sites like LinkedIn, people have seen remote work as difficult, dangerous, a godsend, the future, or an effect of the pandemic that will soon be shaken off.

I wanted to take the opportunity to talk about how RunX has succeeded by embracing remote work, and why other startups will need to let go of locality if they don’t want to limit their growth.

The Limiting factor in cloud growth: people

In 2018 I gave a few talks about the difficulties in hiring experts in containerization, which included the throwaway line: “talk to any CTO and they’ll tell you that it’s hard to hire qualified people, when’s the last time a CTO complained they couldn’t find enough RAM?”

Sadly that little quip is a bit less timely given the current chip shortage, but even if you’ve been waiting six months for a GPU, the point still stands. Where once hardware purchasing could present a hard limit on your IT Operations growth, now the limiting factor is almost always the trouble of staffing and maintaining a team of skilled operations engineers.

Wait, what does any of this have to do with remote work?
I know this has been a hard year and a half for all of us. And for some of us, part of the pain of this time, along with the constant fear and knowledge that western liberal democracies don’t care about the welfare of their citizens, being cooped up in our homes wasn’t always fun. But for those of us lucky enough to still have jobs, and homes, remote work has meant a major upgrade to a previous commute heavy existence.

As our children return to school we’re able to spend an extra hour with them every single day. And our trips to school can happen with any parent now that we don’t have to get to a downtown office.

Days where you have two meetings, one at 8 am and the second at 3pm, can be spent in relative leisure rather than furtively reloading twitter at your desk. And if a day has more than 8 hours of work stuffed into it, well at least you’re home to have dinner with your family.

But as the pandemic stretches into its second year, people’s lives are shifting more fundamentally. People are re-locating to homes that more suit their daily lives. More than one of my own co-workers has gone from semi-urban wasteland to bucolic bliss, complete with solar panels and a goat herd. Others are living closer to family, while still others are planning multi-year global tours.

As numerous large tech companies prepare to ramp up their long-silent offices, they have little to offer in compensation for these lost benefits beyond K-cups and artisan burritos. Major players like Apple and Facebook have shown more willingness to force their employees to commute. Their confidence stems possibly from the knowledge that, paying the highest salaries in the industry, their employees will need to take a pay cut to leave.

Go Big and Go Home

Now perhaps you see the connection between remote work and the difficulty of hiring and keeping good people. If you are incapable of paying half a million dollars for every engineer as the FAANG companies do, you will be hard pressed to keep them if you insist they fight for domestic real estate in the bay area.

But the most successful teams won’t just say ‘remote OK’ and leave it at that. I’m working next on a piece about how remote teams differentiate themselves. In the meantime, comment down below with what benefits you expect in a remote team.

Docker Images in Kubernetes : Image tags vs. Digest

Nilesh Sarupriya — Tue, 14 Sep 2021 18:07:17 +0000

Ever faced below problems with Images

I am unable to see my changes, even though I am using the referencing the image using the Correct Tag.
- Software Engineer developing something

I haven't changed the Referenced for the Image, but its behaviour changed.
- Software Engineer using something

What is Referencing?

This is useful when versioning attached to the resources is immutable. But at times, situations arise where one wants to have even more readability, for ex., using the latest version of the resource every time or raising a small patch so that it reflects in the version. In such cases, we would require the tags to be mutable.

Referencing in Docker Image in K8s

The usability around which the Docker Registry HTTP API V2 was built was to have Immutable references to the Images.

Having mutable tags gives the ability to have named versions, something which makes a lot of sense because things are kept easier on the pipelines, like take the latest image, use the dev image, or maybe when a fix is so small that it doesn’t require a version update.

So, now that the versions, a.k.a., tags, are mutable, does that mean there is nothing immutable that can be used to get the same Image again and again. This is where the Digest comes into the picture. This is a hash key that is created based on what all base images are used for constructing the image and this is unique for every different image. Same Digest can be used to reference the same image again and again.

Now let’s get into some techie stuff

Why are tags important?

What is Non-deterministic Deployment?

When using Image tags for referencing the Image, there is no guarantee that the Tag would refer to the expected Image, because of Tag Mutability.

This drawback is for the Infrastructure Tools, which depend on State Changes, as the tools will not be able to find the difference in the state, if the Tag refers to a different image or not.

So, how do we make this deterministic?

In order to get the best of both the worlds, that is human understandable reference as well as deterministic deployments, there needs to be a Dynamic Mapping between Image Tag and Image Digest which can be used when deploying images. While pushing to a repository, we can tag the image and then once the digest is created, use that to deploy the images.

How can OPTA help?

What is Opta?

Opta is a platform for running containerized workloads in the cloud. It abstracts away the complexity of networking, IAM, K8s, and various other components - giving you a clean cloud agnostic interface to deploy and run your containers. It’s all configuration driven so you always get a repeatable copy of your infrastructure.

How does Opta help?

The "deploy" option of Opta with an image tag input would automatically create the Dynamic Mapping between the Image uploaded to the Repository and use the Image digest to deploy the Image. This guarantees that the new image is used every time regardless of the tag.

For more information on how to use Opta, please visit: https://docs.opta.dev/getting-started/

How to Deploy Wordpress to Kubernetes on AWS

Nočnica Mellifera — Tue, 14 Sep 2021 14:04:27 +0000

Introduction

The first time someone suggested adding Wordpress to the Awesome Kubernetes list, I was surprised! I didn't think of Wordpress as something that needed a distributed workload tool. So many readers mentioned it that I put together this brief tutorial.

This article analyzes available paths for migrating a WordPress website to AWS, and the architecture components for AWS-hosted WordPress. This instruction to covers how Opta can be used to provide shared storage on the AWS EKS platform for a WordPress CMS.

Overview of WordPress

WordPress is a simple (CMS) content management system, a process of posting articles and media to a website. WordPress was born as a blogging platform but has grown to support the creation of all kinds of websites. It is free and open-source. It was launched in 2003. It has mainly two basic elements that are the front end and the back end. WordPress provides a spontaneous user interface for this purpose for show text, images, and other media to the web. Anything users see on the website has been uploaded to the webserver. As of 2021, more than 42% of the top 10 million websites are running WordPress.

Alternatives for WordPress on AWS

WordPress has been developed to combine CMS competence that integrates with modern elastic, scalable, and cloud-native architecture. The WordPress group has attempted to develop modules that enable the creations of WordPress sites that exploit AWS Cloud contributions.

AWS provides a large-scale cloud platform that improves performance, control, scalability, and reliability for WordPress websites. The Amazon web services Elastic Kubernetes Service grant the company to build, manage and scale Kubernetes clusters on AWS cloud or local tools.

There are the following options in AWS when going for WordPress hosting as per utilization cases changes:
a. AmazonEC2 -- The EC2 virtual machine system is the classic way to own your own virtualized server on AWS. But the smooth scaling and automated restarting of instances aren't included

b. Amazon LightSail -- It is simple to apply a single-instance virtual private server that abstracts all instances needed to run a simple workload or quick deployment.

Image Source: https://aws.amazon.com/blogs/

For small WordPress websites, it acts as a perfect starting point that can scale later with its growth.

c. AWS marketplace --It includes different pre-configured WordPress images that can be deployed into AWS EC2 in quick time. That single-click deployments are tailored to unique work and come in an adjustable combination of packages and plugins for efficient use of computing resources.

WordPress Hosting Components

While most WordPress organizations utilize speedy begins to enable automated arrangements dependent on best procedures, comprehend the parts that make up a working WordPress application in AWS cloud.
WordPress app. requires components to perform four functionalities:

Static Host Content
Dynamic host content
Blog/site store content/data
On the file system store uploaded files and images.

Now there we will discuss how above each functionality can be managed for AWS.

Stateless Web Tier

In a stateless web tier, the server does not keep any data from one request to the next. The user needs to do its work in a series of simple transactions, and the client has to keep track of what happens between requests. While sessions are maintained by cookies on the end-user’s web browsers, so the WordPress core is stateless.

Scaling Web Tier

It is defined as having the capability to link resources to a system that increases its performance (decrease output times or increase throughput). The number of compute instances includes by AWS that can be used to evolve single-server applications into scalable architecture.
There are about five main components included by scalable web tier to handle scaling for dynamic content:

Amazon Machine Images (AMIs)
Amazon EC2 Instances
Load Balancing
Automatic Scaling
Health Checkup

Shared Storage

Mostly all WordPress Installation files, and client customizations should be handled in a shared platform as this eases the strain on web servers. Amazon web services having the Elastic File System (EFS) which gives a scalable, highly networked file system for different compute instances.
Data Tier
When the WordPress installation data files and setups are moved into a common Network File System (NFS), and static resources are being served on S3, stateful parts are hosted on WordPress Databases. Amazon Aurora is the top solution for running stateful workloads for AWS applications. Both MySQL and PostgreSQL are compatible with this stage. In Opta we will use PostgreSQL.

What is Opta?

Opta is a stage for running containerized jobs in the cloud. It abstracts away the intricacy of networking, IAM, Kubernetes, and different parts - giving you a perfect cloud skeptic interface to deploy and run your containers. It's all arrangement or configuration driven so you generally get a repeatable duplicate of your foundation.

Setting up Opta

Before starting with WordPress, we need to set up Opta. For this article, we will be used Opta.
To set up Opta, install Opta by using the following command in a Linux distro like Ubuntu.

/bin/bash -c "$(curl -fsSL https://docs.opta.dev/install.sh)"

Set-up environment Creation
An organization like AWS or Azure, we will set up an environment by executing the following commands:

opta init env (AWS)
Creating a file opta.yml to describe an environment that you will create. Using the below command and hit then a description of the environment will start showing and a cluster will be created.
Cluster Creation
Using the below command, we can create yml file that is responsible for the initial configuration for your environment and architecture setup.
cat opta.yml
We have seen the first part we will mention about the AWS region and create account id through AWS console, now the second next part we will link modules through setting up Kubernetes or k8s cluster and created several nodes.

name: aws
org_name: XXXX
providers:
  aws:
    region: ca-central-1 
    account_id: XXXXXXXXX254
modules:
  - type: base
  - type: k8s-cluster
  - type: k8s-base

After that execute the command opta apply
When the above command gets executed, we will create an EKS cluster for you and configure VPC, networking, and different other infrastructure pieces.

Implementing WordPress on AWS using Opta

Kubernetes empowers quick scaling of web applications utilizing on-request Horizontal Pod Autoscaling (HPA) approaches. An increment in workload pushes Kubernetes to plan extra reproductions utilizing extra PODs hosting comparative data content. Kubernetes also utilizes rollback arrangement systems to aid in seamless updates for content, client uploaded files. that is the reason a WordPress hosting application on the AWS Elastic Kubernetes Service improves to implementation of scalable, high accessibility websites.
Now we will learn and understand how to provide shared storage to WordPress sites running on EKS which require access to shared volumes.

Kubernetes Access Mode is a specification of a Persistent Volume that defines how it is mounted on a host. Various storage providers help various capabilities and the mode for each Persistent Volume is set to the specific combination of access modes it supports.
There are four types of access mode supported by Kubernetes:

Read-only Memory
Read WriteOnce
Readwritemany
ReadwriteoncePod

Conclusion

In this article you have learned what opta is and how it is involved with deployment process, and this article explained from basic to the concept behind the deployment of WordPress on AWS using opta. If you have any trouble with the process please comment down below or join the opta slack.

DevOps Is Not Automation

Nočnica Mellifera — Wed, 08 Sep 2021 09:42:46 +0000

Image by Kharnagy, shared via CC Attribution-ShareAlike 4.0 International License.
The Puppet 2021 State of Devops Report highlights that DevOps is now cemented as standard industry practice, whereas previously it had been the product of a “vibrant, enthusiastic,
and productive community, vigorously debating and sharing methodologies.” DevOps becoming an institution is in some ways a great thing, but it also makes it important for teams attempting to incorporate DevOps practices to remember that DevOps is not (or at least not just) automation.

As the report highlights: plenty of teams and companies use a high level of automation but are still not achieving the goal of DevOps, which is continuous production. The 2021 report points out that a highly evolved DevOps team using automation can roll out new software changes in under an hour with a very low failure rate. Meanwhile, miid-evolution teams, which often report a high level of automation, are lagging significantly behind that, rolling out changes in days or weeks. So why might two highly-automated teams differ so widely in terms of their ability to deploy?

The answer is culture. A highly-evolved DevOps team isn’t just about automating processes; it’s about eliminating production roadblocks. Automating processes without making changes to how your teams communicate is just moving the roadblocks around.

A key first step to truly effective DevOps is to synchronize development and operations teams--teams that in traditional tech culture are siloed--and in fact, often at odds. Forte Group points out that that typically, development teams are incentivized to push things forward (get their deliverables in on time) and quality assurance teams and system administrators are incentivized to minimize disruptions (which often means pushing back deadlines to focus on a quality product). In order to create a culture where continuous development is possible, these teams have to think of their work as sharing an objective. Additionally, they need to communicate frequently and effectively.

DevOps also requires a shift from one big deliverable at the end of a long development period to small, incremental deployments that happen regularly and are constantly being monitored and adjusted. The principle of CI/CD, requires a big shift in company culture. While automation is a part of CI/CD (especially if continuous deployment is also part of your structure), the principle that allows CI/CD to succeed is the ability to make mistakes. Expecting a certain amount of failure and building in a margin of error represents a big change from trying to put out a perfect product and then assigning blame when the product inevitably isn’t as perfect as anticipated. This model of releasing things as long as they are within an exceptional margin of error, and testing them in the field, can be emotionally challenging. If it’s going to work, teams and managers have to get good at not punishing each other for the inevitable failures that are part of this iterative process.

These changes can be a big shift for a company that typically operates on a more traditional model. Gartner, Inc states that it can be best to introduce the principles of DevOps to a few select teams first, to allow them to model behavior for the rest of the company later. They state that leaders should “focus their efforts on an initial, small [DevOps] team, establish the values and behaviors needed, and take incremental efforts to recognize and reinforce desired outcomes prior to scaling." This prevents a situation in which a CEO imposes DevOps principles on a whole company from the top down without taking the time to see how DevOps mixes into the existing company culture. Changing incentives and manager behavior takes time even if everyone on the actual team is onboard, and having one success story can be a selling point for adopting the principles company-wide.

So: if your CEO is expecting a pivot to DevOps without laying out a clear plan for how incentives and communication are expected to change, it’s likely that your company will be in the majority that won’t get the benefits of rolling out DevOps correctly--faster delivery, acceptable margins of error, efficient use of automation, and strong collaboration. Any company that’s going to get to “highly evolved” DevOps is going to need to examine what they reward and penalize, and how teams talk to one another.

Do you love programming?

Nočnica Mellifera — Thu, 02 Sep 2021 17:47:25 +0000

cover image by Chrys Omori CC BY 2.0

I've talked before about how passion shouldn't be a job requirement. Now I just want to ask you personally, do you love programming? Or is it more of just a job?

I love programming on my own projects. My toys, my own interesting things, that's super fun.

I don't particularly care for programming when it's pumping out features as part of a corporate shop.

What about you?

Is your microservice architecture just a monolith wearing a bunch of smaller trench coats?

Nočnica Mellifera — Tue, 31 Aug 2021 16:20:32 +0000

Image by Frycenty, shared via Attribution-ShareAlike 4.0 International.
If you’re migrating to a microservice architecture, it’s possible you’ll run into this issue: your services are all going down at the same time, which you were promised wouldn’t happen if you moved away from a monolith model. Why is this happening? Where are the benefits of the microservice model that you were promised? It’s worth examining whether your microservices are actually as siloed as you think that they are.

First, some background. The key difference between a monolith and microservices is that the monolith model creates a cohesive single programming ecosystem that has everything it it that you need to run your whole setup. So if you’re designing a web store, your product search function is dependent on your inventory system, which is dependent on your pricing and billing system. The benefit of the monolith model, of course, is that it’s simpler to build and test. You just run the program, and see if everything works. However, if you change one thing in that chain, it affects everything else. DevOps aims to get away from the monolith model because it means that in order to launch, your product needs to be flawless, or as close to flawless as it’s ever going to get. In a monolith, updates are a pain because of interdependency--you have to redeploy the whole application with every update and then see if it works, rather than constantly iterating on specific services. And if you want to adopt a new technology or framework, you have to do it across the whole application: effectively a whole new version, when really you just wanted to update one function.

A microservice model aims to decouple a product’s functions from one another so that they can run independently and be managed separately. You could, in this model, take your billing software offline for an hour or two without disrupting your whole operation, or even have a version of your billing software running on some of your servers while you test out the new billing program on others. This is what allows CI/CD to happen.

But you might notice that if implemented incorrectly, your microservice model has all of the redundancy of microservices and all of the interdependency of a monolith--meaning that effectively you just spent a bunch of extra time developing separate services that still crash when everything else crashes. What gives?

The answer may be in your coupling. A loosely coupled chain of microservices is not interdependent, and should “know” as little about the other services in the chain as possible--i.e., your billing service should not be dependent on anything happening in your search function to work, although it may need to receive input from your purchasing service. As Yusuf Dagtekin points out, “When microservices are not split in the right way, this creates tightly coupled microservices that will have all the disadvantages of a monolith and all the complexities of microservices, aka a distributed monolith.” He points out that a frequent source of tight coupling is any requirement for synchronous communication between services--that, effectively, makes everything you do dependent on the slowest service in the chain.

There is a case to be made for specific instances of a “minilith” as David Dawson calls it--tightly coupling some services that function as a unit. However, he points out that this makes them “effectively version locked”, reducing some of the benefits of using the microservice model. This might be worth it for a few services within a larger architecture, but if you’re tightly coupling everything, you might as well make it a monolith.

I made a list of Awesome Kubernetes libraries, what should I add?

Nočnica Mellifera — Thu, 26 Aug 2021 20:52:33 +0000

Cover image by Christian Ferrer / Wikimedia Commons, CC BY-SA 4.0

We're pleased to share with the world our awesome Kubernetes list. The focus of this list is for Kubernetes developers looking to build production applications.

For context, it's a running theme on Github to release documentation-only repositories with your favorite content on a language or framework. Here's a list of awesome lists.

It was an "awesome" list that gave me my first tour of a number of GraphQL tools, so I'm excited to share my own.

Some highlights:

Teleport allows engineers and security professionals to unify access for SSH servers, Kubernetes clusters, web applications, and databases across all environments.

Certmanager provides 'certificates as a service' securely to developers and applications working within your cluster.

Here's a talk we really enjoyed: Keynote: In Search of the Kubernetes "Rails" Moment - Bryan Liles

Check out our awesome list here:

https://github.com/run-x/awesome-kubernetes