Multi-stage builds in Docker are powerful, enabling streamlined images and optimized build processes by allowing each FROM statement to start with a fresh layer. However, a known limitation is the inability to natively share environment variables between stages. Environment variables set in one stage aren’t directly accessible in subsequent stages due to Docker’s isolation design for layers.
To transfer environment variables, developers use workarounds like writing variables to a file and copying it to subsequent stages. For example:
dockerfile # First Stage FROM base-image AS stage1 RUN echo "MY_VAR=$MY_VAR" > /env_vars
# Second Stage FROM final-image COPY --from=stage1 /env_vars /env_vars RUN export $(cat /env_vars)
This approach reads from a file to replicate environment variables, providing a way to reuse configuration across stages despite Docker’s isolation boundaries.
With the current state of the market in software engineering, I can understand there are people out there who cannot find a decent and stable job. I might be exaggerating, but I do believe that the “peak” of software engineering was reached in ’21. It’s all downhill from there on.
Returning to a former job can be appealing for those seeking stability, familiarity, or a role they truly enjoyed, but it’s a decision that requires careful consideration. Especially in software engineering, and in the software industry, where job hopping is considered the norm. I will try to analyze a breakdown of the pros and cons.
Pros
Familiarity: You already know the team, culture, and work processes, allowing for a smoother transition.
Shortened Learning Curve: Since you’re familiar with the role, you can often pick up where you left off, leading to quicker productivity.
Potential Respect or Promotion: Returning employees are sometimes valued for their previous loyalty, especially if they left on good terms, which could open doors to promotions or new responsibilities.
Cons
Stagnation: Returning could limit new learning and growth, as it may feel like going back instead of moving forward in your career.
Possible Tensions: If you left for reasons related to culture or management, those issues might still be there.
Missed New Opportunities: Going back might prevent you from exploring fresh environments or companies that could offer new perspectives, skills, or compensation.
Mr. ChatGPT, could you please…?
The above, just as you guessed, came from a single, one-liner prompt:
Write the pros and cons of returning to your old job.
While I can see the reasoning behind it, and most of the pros do make sense, my belief is that the scale tips towards the cons. As usual, I’ll try to elaborate my train of thought.
Being primarily a millennial, when it comes to the job market, I was born on the wrong side of the history. Right when I managed to make a break and by shedding tears and spilling blood, graduated from my masters, I ended up right in the big financial crisis. Businesses closing down, political unrest, and not to mention that my current job aspirations were describing a profession that, at the time, half of the people could not grasp it even.
Therefore, just as my other peers born on the cusp of the millennia, we believe that having a job is actually a blessing than a burden. So, millennial compromise usually outnumbers gen z’s pickiness, or general “high maintenance” of all the younger people joining the industry. Hence, if usually millennials are changing jobs, they do so because there are strong reasons behind them.
Familiarity
The kind of reasons, once accounted and acted upon, do not easily change. Hence, the pro argument of Familiarity is a strong con. What would be the reason of returning to the old job, if, there was a familiar strong reason for leaving? If that reason has changed, yes, it makes sense, but this leads to other…kind of arguments (essentially a different company, or position), so let’s not explore that.
Shortened Learning Curve
This argument, while seems to be a big positive one, I will try to reverse it.
Indeed, since an employee left, was familiar at the least, or was doing a very good job at best, in his/her previous post. That leads to shorter time to production and increased productivity. However, we do not fully know the reasons for leaving (whether that was compensation based, or something else), but for most of the people in the industry, a short learning curve is something they generally avoid. Not learning something new (especially with all the new tools that come up every day), is considered to be job-killing. Not to mention the challenging part. It is extremely challenging to be able to comprehend, learn and adapt in order to fix something broken. Or create something new.
Potential Respect or Promotion
I cannot think a worse argument than this. The main reason behind it is quite simple. If there was enough respect, there would have been a promotion, and the employee would not have reached the exit door. GPT, is also mentioning “loyalty” and “leaving on good terms”. Both of those things are, obviously discarded, right from when someone opens the exit door…
Concluding
Returning to a former position for me does not really make any sense. Being an advocate of change and generally positive feedback, when someone leaves his post, there surely is a larger reason that has not change for him to return. If that reason has changed, the most of the times we are talking about a different company, with different managers and different colleagues. Not the same company anymore…
To quote the big economist: “This time is different”. No — this time its not different than the previous time, at least not in the software industry.
In the rapidly evolving world of technology, few tools have garnered as much attention as Kubernetes. Often hailed as a silver bullet for a multitude of IT challenges, Kubernetes is touted as a panacea for managing containerized applications. But is this perception grounded in reality, or is it merely a myth? In this blog post, we will delve into the capabilities and limitations of Kubernetes, exploring whether it truly lives up to the hype.
What is Kubernetes?
Kubernetes, often abbreviated as K8s, is an open-source platform designed to automate the deployment, scaling, and operation of application containers across clusters of hosts. Originally developed by Google, it is now maintained by the Cloud Native Computing Foundation (CNCF). Kubernetes provides a framework to run distributed systems resiliently, handling scaling and failover for applications, and providing deployment patterns and management tools.
The Promises of Kubernetes
Scalability: One of the most significant promises of Kubernetes is its ability to scale applications seamlessly. It can automatically adjust the number of running containers based on the current load, ensuring that applications remain responsive and efficient under varying demands.
Resilience: Kubernetes offers robust mechanisms for managing the lifecycle of applications. It ensures that your applications are always running in the desired state, automatically restarting containers that fail or are unresponsive.
Portability: Kubernetes abstracts away the underlying infrastructure, making it possible to run your applications on any cloud provider or on-premises environment. This portability is a key advantage for businesses looking to avoid vendor lock-in.
Efficiency: By optimizing the use of resources through its scheduling capabilities, Kubernetes can lead to more efficient utilization of hardware, reducing costs and improving performance.
Automation: Kubernetes automates many aspects of application management, including deployment, scaling, and operations, freeing up developers and IT staff to focus on more strategic tasks.
The Reality Check
While the promises of Kubernetes are compelling, it’s essential to recognize that it is not a magic solution that will solve all problems effortlessly. There are several considerations and challenges that organizations must be aware of:
Complexity: Kubernetes has a steep learning curve. Its powerful features come with a complexity that can be overwhelming for teams new to container orchestration. Proper training and expertise are required to harness its full potential.
Resource Intensive: Running a Kubernetes cluster can be resource-intensive. The control plane components and various add-ons needed for a production environment can consume significant CPU and memory, which may not be ideal for small-scale applications.
Operational Overhead: Despite its automation capabilities, Kubernetes still requires significant operational oversight. Maintaining, updating, and securing a Kubernetes cluster involves ongoing effort and vigilance.
Security: Kubernetes security is complex and multi-faceted. Misconfigurations can lead to vulnerabilities, and securing a cluster requires a thorough understanding of Kubernetes security best practices and continuous monitoring.
Integration and Compatibility: Integrating Kubernetes with existing systems and workflows can be challenging. Not all applications are designed to run in a containerized environment, and some may require substantial refactoring to be compatible with Kubernetes.
Database Migrations: One of the notable limitations of Kubernetes is its inability to manage complex database migrations effectively. While Kubernetes excels at managing stateless applications, handling stateful components like databases and their intricate migration processes can be cumbersome. Database migrations often require precise sequencing, careful coordination, and rollback mechanisms that go beyond the orchestration capabilities of Kubernetes. These tasks often necessitate external tools and manual oversight, underscoring that Kubernetes is not a comprehensive solution for every aspect of application deployment and maintenance.
Use Istio
Attending recently a potential candidate meeting, the candidate was asked to “provide a system solution that would solve the most common issue found in a live-update system: uptime“. The requirements were simple. You have a system that is broken into two parts:
Backend.
Database.
Using k8s what would be the ideal setup you would choose so that you can update your Backend code, while also doing a database migration?
For example, say the backend code is compatible with the db code at major version X, what happens if you upgrade to the major version Y, and you need all your users to be serviced with 0 (literally 0), downtime?
The candidate, responded, after thinking a bit, that you need, in the between to deploy a backwards compatible version, so as to give a chance to the migration to take place.
This was unacceptable of course according to the interviewer. The answer from the interviewer was to : Use Istio.
What does this Istio thing:
Traffic Management: Imagine you have a bunch of tiny services (like small programs) that need to talk to each other to make a larger application work, much like how team members need to communicate to complete a project. Istio acts as the “traffic controller,” making sure these messages go to the right place, in the right order, and without getting lost. It can also control how much traffic goes to each service, balance the load, and handle failures gracefully.
Security: Istio makes sure that communication between services is secure. It’s like locking all the doors and windows in a building to ensure that only authorized people can enter. Istio automatically encrypts the data being sent between services and checks that each service is who it claims to be (authentication). It also enforces rules about who can talk to whom (authorization).
Observability: Istio helps you keep an eye on what’s happening inside your application. It’s like having a surveillance system that monitors traffic, performance, errors, and other important metrics. Istio provides insights into how services are interacting, which can help you quickly identify and fix issues.
Policy Enforcement: It ensures that certain rules are followed. For example, it can enforce limits on how much data one service can send to another or ensure that certain services are only accessible under specific conditions. It’s like having company policies to ensure everything runs smoothly and safely.
Ok, so my guess is that the interviewer had read the above bullet points and thought:
Hmmm, smart traffic management looks like can be used so that we can route traffic from the database while running a migration in a way that it would never stop servicing at all!
Well, that was correct. Except that the database is a central place that gathers all application traffic and requires a central semaphore to perform write applications. This main’s semaphore’s task is to allow or not allow one agent writing or non writing. That means, when you are running your migration and you are changing the columns of a table, the RDBMS needs to have exclusive access to that table in order to recreate it, and no one else is allowed to write there. No matter how smart you will route the pod logic and traffic, the end bottleneck would be the database.
Kubernetes: Panacea or Powerful Tool?
Kubernetes is undoubtedly a powerful tool that can transform how organizations deploy and manage applications. It offers unparalleled capabilities for scalability, resilience, and efficiency. However, it’s not a one-size-fits-all solution. The notion of Kubernetes as a panacea is a myth if taken to mean that it can solve all IT problems without effort or expertise.
The reality is that Kubernetes can provide immense benefits when used appropriately and with the right level of investment in knowledge and resources. Organizations should approach Kubernetes with a clear understanding of its strengths and limitations, ensuring they have the necessary skills and infrastructure in place to leverage its full potential.
In conclusion, Kubernetes is not a magical cure-all, but it is a powerful tool that, when used correctly, can significantly enhance the agility, reliability, and scalability of modern applications. By setting realistic expectations and preparing adequately, organizations can avoid the pitfalls and maximize the advantages of adopting Kubernetes.
