[{"body":"","link":"https://pconte.tech/categories/ai/","section":"categories","tags":null,"title":"AI"},{"body":"","link":"https://pconte.tech/tags/ai-engineer/","section":"tags","tags":null,"title":"AI Engineer"},{"body":"","link":"https://pconte.tech/categories/article/","section":"categories","tags":null,"title":"Article"},{"body":"","link":"https://pconte.tech/tags/career/","section":"tags","tags":null,"title":"Career"},{"body":"","link":"https://pconte.tech/categories/","section":"categories","tags":null,"title":"Categories"},{"body":"","link":"https://pconte.tech/tags/job-market/","section":"tags","tags":null,"title":"Job Market"},{"body":"","link":"https://pconte.tech/","section":"","tags":null,"title":"Patrick Contes blog"},{"body":"","link":"https://pconte.tech/post/","section":"post","tags":null,"title":"Posts"},{"body":"","link":"https://pconte.tech/tags/recruitment/","section":"tags","tags":null,"title":"Recruitment"},{"body":"","link":"https://pconte.tech/tags/salaries/","section":"tags","tags":null,"title":"Salaries"},{"body":"","link":"https://pconte.tech/tags/software-engineering/","section":"tags","tags":null,"title":"Software Engineering"},{"body":"","link":"https://pconte.tech/tags/","section":"tags","tags":null,"title":"Tags"},{"body":"I\u0026rsquo;m a frequent user of Reddit. I find it fascinating some of the stories that I read, from AusCorp, where someone is complaining about having to do a white collar role for the next 40 years and being miserable. To a post on GardeningAustralia, asking if yukkas are a good idea to keep long term. Everyone has something to ask, something to share, and something to ponder.\nRecently, I came across a post in the AustraliaIT sub-reddit with this picture:\nAt first, I\u0026rsquo;m thinking to myself (like most things I now see on the internet) \u0026ldquo;surely this can\u0026rsquo;t be legit. Surely someone has fabricated this to be ragebait to get a rise out of others\u0026rdquo;. I was wrong. It really is a job that was posted on a jobs board website. Now, before I get angry people saying that job postings are not vetted by any entity (aside from if they are illegal or use inappropriate wording), I get that some agencies will try and use jobs boards to harvest personal information to build profiles. I\u0026rsquo;ve heard of it happening. It\u0026rsquo;s rather appalling behaviour, especially with how often we now hear about websites getting hacked and our personal information gets stolen. I suppose when we think of IT, we need to remember what the I stands for. At the end of the day, it\u0026rsquo;s all information. But it is just so vast now, that it encompasses many elements of our lives.\nJob postings of this nature are amusing at best, and highly detrimental at worst. They set a precedence for the future and attempt to capture incredibly unrealistic expectations for both employers and employees. This kind of thing really needs to stop lest we have people in roles that will drive them to an early grave.\nActual jobs/careers in this posting Let\u0026rsquo;s start with what some may perceive as obvious, where others may legitimately be confused: the number of roles here. This is a rough breakdown of what I came up with:\nAI/ML engineer: Very hot at the moment, given the nature of Generative AI. Full stack engineer: This could even further be split between the actual key skills of frontend and backend. However, full stack roles are a thing which is seen as the end game of the software engineering pathway. Data engineer/scientist: Working with all things data is in and of itself absolutely a profession. Cloud/DevOps engineer: These are now quite interchangeable. You normally will not find a cloud engineer who doesn\u0026rsquo;t know or do DevOps. ClickOps is not the way anymore. At a stretch, you MAY be able to include a MLOps engineer\u0026rsquo;s capabilities into this role. To be fair, I haven\u0026rsquo;t included this as a separate role as it is technically possible to do all 3 but you need to be damn good. Database engineer: A database engineer (or a DBA as we normally refer to them) has to be able to handle the actual database engines. This is not the same as a data engineer/scientist, although there is some overlap. Architecture: Architects come in multiple forms, but for the sake of argument, we will simply say this is a role in itself. At the very least, we have 6 roles here. Not to mention, if you had a single person doing this role, with all of the criteria mentioned, anything short of $500k/year would be underselling the capability that this person would have. Take my career as an example. I\u0026rsquo;m currently as of September 2026 a Senior Cloud Engineer. My background is on-premise infrastructure which eventually branched into cloud and DevOps. I have 15 years of experience, and still there are many elements of my role that could be tuned. Not only could they be tuned, there are technologies that are within my wheelhouse that could be tuned. A large one of this is container orchestration, which is basically Kubernetes.\nIt begs the question of why even bother? Why try to do something like this, risk reputational damage and look for something that is just not possible? The person doing this role would have to be on par with Sheldon Cooper in terms of intelligence. And let me tell you, they are probably already working at a tier 1 company creating the next generation of technologies.\nFalse precedence and unrealistic expectations As I covered before, most people in the tech/IT industry will take one look at this job and chuckle at how ridiculous it is. 6 roles (at least, there could even be more) in 1? You\u0026rsquo;ve got to be joking. Clearly this isn\u0026rsquo;t possible. Yet somehow, someone was convinced this was a good idea? That or they didn\u0026rsquo;t really care about the job and were really farming for leads from potential engineers where even 20% of the criteria were met.\nThe problem isn\u0026rsquo;t folks who have been in IT long enough. The problem is young talent wanting to explore a career in IT. I could write another entire blog on why it\u0026rsquo;s so challenging to break into the market now. When you have a young person who is at the crossroads of what to do after school, and looks at something like this job, they would treat this as a normalised role that is the future. Nothing could be further from the truth. However, because they are so impressionable at this age and want to make it, they will try to aim for most of the criteria that are specified. Imagine applying for a role at a supermarket. The criteria for the role are:\nStack shelves Serve customers at the checkout Receive goods Manage the deli Serve as store manager Sounds moronic, right? This is honestly no different. It\u0026rsquo;s trying to cram several roles into one, and it just doesn\u0026rsquo;t happen.\nAI engineer != everything engineer We have to pause and ask ourselves how this is possible and why this is happening. The answer is a rather convoluted one. IT in the modern era started out in the 1990s when the first websites started to come online. They were run on first generation NeXT Computers, which was hardware produced by a company founded by Steve Jobs in 1985. Ever since these early days, we have not stopped growing and evolving our technology landscape. Whenever products became functional, they were utilised to their full effect. In an iterative fashion, hardware and software underwent constant evolution. In the infrastructure space we saw many pioneering moments. These moments led to entirely new generations of how we approach IT as a whole. Here are some key moments in the infrastructure space:\n1993: Windows NT 3.1 is released with domain management Novell Netware did it first, but Microsoft were able to market better and eventually squeezed them out 2000: Windows Server 2000 introduces Active Directory 2001: VMware releases ESX server: the first bare-metal hypervisor 2006: Amazon launches S3 and EC2: the start of the entire hyperscaler era 2013: Docker is opensourced, allowing for Docker 1.0 to be released in 2014 2014: Google announces Kubernetes. In 2015, Kubernetes 1.0 ships and is donated to the CNCF 2020: GPT3 is released: the first LLM that is a genuine step-up 2022: ChatGPT is launched and is mass adopted Throughout this time, engineers who have been around for at least 12+ years have had a sampling of many of these technologies. As a result, they have been \u0026ldquo;conditioned\u0026rdquo; to be adaptable to the rapid evolution of the IT industry. Despite some of this technology now being over 20 years old (I\u0026rsquo;m looking at you, Active Directory), it is still prevalent. Not only is it prevalent, it\u0026rsquo;s still critical infrastructure. As a result, newer roles could not simply discard these legacy technologies because they aren\u0026rsquo;t legacy at all! Nowadays, especially in the platform engineering space, you need to have an understanding of at least 70% of the technologies mentioned. If you don\u0026rsquo;t, gaps can be bridged by doing research. However, you need to have a strong fundamental understanding of your craft. I still, to this day, use my Windows Server knowledge that I first started to obtain in 2013.\nWhere does this lead us? It leads to what I call melting pot roles. These are your catch-all roles, that basically have evolved with the industry and accumulated knowledge. Platform engineering is a great example, where you need to understand not only the tech stacks mentioned, but concepts to support them. AI engineering, even though it has its own set of tools, is now shifting into what platform engineering is, with yet another iteration of tools that engineers are expected to know and understand. While technically it\u0026rsquo;s possible, finding these engineers (with a reasonable ask for the criteria, not everything under the sun) is difficult. Commonly they are referred to as unicorns. As someone who is in this space, it feels normal to me because that\u0026rsquo;s just how my career has panned out. For others, especially those coming in within let\u0026rsquo;s say the last 7 years it probably feels a lot different.\nSalary squeeze given financial circumstances Within Australia, like with many other countries, there is uncertainty. The uncertainty stems from many factors. This is compounding into issues where being made redundant from tech jobs is not uncommon. It\u0026rsquo;s becoming more common, as roles are either off-shored or are replaced* by AI. As a result, there is more talent on the market that is desperate for a job. Companies and recruiters are capitalising on this by offering lower salaries and day rates. It\u0026rsquo;s classic supply and demand, so before you get upset that companies are devious, we live in a capitalist society. I agree that there is too much power now in the major financial institutions, and it feels incredibly tone deaf when they gloat about multi-billion dollar profits when many of us are literally struggling to live. However, this is the nature of things. As they are.\nFor the job itself that I\u0026rsquo;m writing about, $120k sounds laughable. How the hell can that be justifiable? Well, tell someone that they no longer have a job, force them to look for roles for weeks or even months, and you start to see how downward pressure is being put on salaries. Still, I will maintain that $120k for this role is indeed laughable, but as has been made very apparent, this \u0026ldquo;Full Stack AI Engineer\u0026rdquo; job shouldn\u0026rsquo;t even exist.\nℹ️ Disclaimer *I don\u0026rsquo;t feel like AI is replacing as many roles as the media would have you believe. I think it\u0026rsquo;s a combination of many things, in the guise of saying it was AI taking the jobs. If you work with AI tools often, you\u0026rsquo;ll know what I mean. Are roles however changing the AI era? Absolutely they are.\nA realistic AI engineer\u0026rsquo;s skillset I\u0026rsquo;m still yet to delve super deep into the world of AI. It is an exceptionally fascinating topic, and when time permits I will continue to up-skill on it. This is an important context, as I can\u0026rsquo;t speak from experience (yet) of what an AI engineer really needs to have skills in.\nIf we think about it, AI roles should have some kind of Machine Learning (ML) background. Model training is not as important from the ground up, given that the large frontier companies (OpenAI/Anthropic/Google) have done the heavy lifting for us. Still, tools and understanding from that discipline do help when it comes to harnessing the abilities of Generative AI. I use the term Generative AI, as AI is an entire field and has multiple AI types. Generative AI is specifically what we are using now in various frameworks such as Agentic AI.\nIt\u0026rsquo;s also important to have some skills from other areas, including both infrastructure and software engineering. Looking at a few jobs on a jobs board, important skills to have are:\nAgentic harnesses (Claude Code, Codex etc) Observability Scripting Cloud technologies Agentic AI (LangGraph is one I see often, along with Strands Agents) RAG (LangChain) MCP This is what a real AI engineer will need to know to be able to be successful. Of course, this list isn\u0026rsquo;t exhaustive and will be situational depending on many factors.\nIf you happen to see a job with this criteria mentioned, rest assured the red flags should not be raised!\nCover image by deepai.org\n","link":"https://pconte.tech/p/the-everything-engineer-why-industry-expectations-are-getting-out-of-hand/","section":"post","tags":["AI Engineer","Job Market","Recruitment","Salaries","Career","Software Engineering"],"title":"The \"Everything\" engineer: Why industry expectations are getting out of hand"},{"body":"","link":"https://pconte.tech/tags/ai/","section":"tags","tags":null,"title":"AI"},{"body":"","link":"https://pconte.tech/tags/democratisation/","section":"tags","tags":null,"title":"Democratisation"},{"body":"","link":"https://pconte.tech/tags/jevons-paradox/","section":"tags","tags":null,"title":"Jevons Paradox"},{"body":"","link":"https://pconte.tech/tags/jobs/","section":"tags","tags":null,"title":"Jobs"},{"body":"","link":"https://pconte.tech/tags/productivity/","section":"tags","tags":null,"title":"Productivity"},{"body":"\u0026ldquo;White collar roles are dead\u0026rdquo;. That seems to be the common theme for most of the stuff I see on LinkedIn, Medium and anywhere else that likes to fear monger. I get it: AI is confronting, and is unlike anything we have seen before. These titles honestly annoy me because they are click-baity and sometimes lack substance. By that, I mean the content of these posts generally is unfounded and misses a whole heap of information. Let me give you an example. You may see a post claiming that a leading SaaS platform is no longer needed, because Little Johnny was able to vibe code a replacement in 8 hours. Or, Little Jane doesn\u0026rsquo;t need to work anymore because she has an army of agents to do everything her role requires. Congratulations, you solved the meaning of life! Little Johnny\u0026rsquo;s app works perfectly fine on localhost, and Little Jane was most likely going to be made redundant anyway!\nSo let\u0026rsquo;s get serious for a minute. AI will, no doubt, change society. It already has in many ways. Cutting code? Seamless with agentic AI using tools like agent skills and MCP servers. Doing mundane tasks on your behalf via a device? Yep, OpenClaw revolutionised that and now there are a heap of players on the market. There is no getting away from it. Things will (and have) changed.\nIt does beg the question though: is my job safe? That depends on the unique value you bring to your role and how well you can adapt. The good news is it\u0026rsquo;s not all doom and gloom. In fact, those who embrace AI tooling and use it to their advantage may find themselves in surprisingly high demand. Enter the Jevons paradox.\nWhat is Jevons paradox? Jevons paradox describes a technological advancement that makes a resource more efficient to use. Rather than demand for that resource dwindling as a result, it actually increases — in an unexpected and counter-intuitive way. The term was coined by English economist William Stanley Jevons, whose example related to coal consumption. When a more efficient steam engine was introduced, coal usage didn\u0026rsquo;t fall — it rose, driven by the new applications the inventor made possible.\nA similar pattern is unfolding with the AI era. Most people expect roles to be completely automated. While this may eventually happen, in the short term (say for the next 5 years), demand for AI will increase. With this, demand for AI skills will also increase. This will have an effect on all white collar roles, where some new roles will be created, some roles will morph into something new, and some roles will completely disappear.\nJevons paradox and the IT industry The barrier to entry for software creation has never been lower. You can now prompt into existence any type of software that you can imagine, articulate and explain. AI models will build it for you in a significantly shorter timeframe than any other software like it. Whether it\u0026rsquo;s enterprise-grade software is another story entirely. Anyone can prompt anything now, but it doesn\u0026rsquo;t make it the next big thing because you can run it locally.\nHaving said all of this, software can now be much more bespoke than it ever was. Take for example a small marketing company who need very specific software for their use case. They can purchase a custom product from a well-known vendor, pay a monthly fee, hit 90% of their use case and be happy. What if, instead of paying for this software, they created it themselves internally? Sure, perhaps most of it is vibe coded and perhaps management of the software is less than ideal, but what if a prototype is built, showcased to the board/C suite level and a business case is approved? A vibe coded product that hits 100% of their use case, and can be further developed internally by proper software engineers means that there will be much more opportunity on the market for those skills.\nInstead of AI taking all of the jobs, it may actually rapidly grow the IT sector with new jobs. Software engineers are but a specific discipline in the IT machine. What about infrastructure, security, management. Not to mention, this could be one of several products that are maintained internally. It does make you think about what really will happen next.\nSaaS disruption SaaS has been a dominant player in the market for many years. Ever since we transitioned from software installed locally to web-based SaaS, it has never gone back. Can you even remember the last time you installed something locally? I\u0026rsquo;m not talking about installing a package via brew, npm or chocolatey. I\u0026rsquo;m talking about getting media in whatever form is standard nowadays, installing it, and running it. It just doesn\u0026rsquo;t happen.\nThere is a change though happening with SaaS, and it ties in with the previous section. Software creation is simple now as we\u0026rsquo;ve covered. If you\u0026rsquo;re able to produce something functional and host it within your datacentre or cloud environment, the cost for subscribing to the SaaS equivalent stops. Yes, that cost may transition to paying a FTE to maintain the product. But, if it works out financially for the company, it\u0026rsquo;s a compelling idea. You\u0026rsquo;re already seeing this happen in the market. The most recent example is Atlassian laying off 1600 employees in March of 2026. The official stance from Atlassian is a mixture of AI enhancement, a changing landscape (ain\u0026rsquo;t that the truth), and more importantly, revenue generation. SaaS companies are very afraid of the new AI age, and rightfully so.\nLean into AI, now As of this post in June of 2026, I have recently started a new role. In my previous role as a consultant, almost everything we talked about was AI related. Conversations would consist of the latest model, a new update to an existing harness, what wacky project someone hatched over the weekend while they had a spare couple of days. The conversations were endless. The best part about all of this was genuine excitement and solid use cases for products that were actually damn impressive. One colleague in particular had developed a bot that could perform QA testing on applications, end to end. It may not sound like much, but it\u0026rsquo;s quite significant in the software field to have this process completely automated and evolve just with prompts.\nThe crux of the point I\u0026rsquo;m trying to make here is that now is the time. Not tomorrow, not next week, not \u0026ldquo;when I get a sec\u0026rdquo;. It\u0026rsquo;s now. If you are just using the web prompters for ChatGPT and Claude, it\u0026rsquo;s time to shake it up. Install a harness (Claude Code, Co-Pilot, Codex) and start playing with its agentic capabilities. It costs money? Pittance compared to what it can do for you. It\u0026rsquo;s worth it. You don\u0026rsquo;t need to get fancy and have an army of agents with personas. Give it instructions as if you were explaining it to someone who was doing a task for you. The better the prompt with rich detail, the better the result you will get. Learn about how agents work, how they use tools, learn what MCP is (albeit that it may not be a thing that is used long term) and learn about agent skills. Hit that moment where you stop and realise \u0026ldquo;holy shit, this is actually legit\u0026rdquo;. The way things were done previously are still possible, but AI will make things easier. It is key that you understand how they work because I can assure you, if you don\u0026rsquo;t learn the tools now, someone who does know the tools will threaten your job. That\u0026rsquo;s Jevons paradox in action — the easier software becomes to build, the more of it the world will demand, and the more it will need people who actually know what they\u0026rsquo;re doing.\nChange is necessary If you decide that AI isn\u0026rsquo;t for you, and you\u0026rsquo;re fine to continue to do what you\u0026rsquo;ve done for the last X amount of years during your career, expect some friction in the future. AI will evolve naturally, and within the next few years, we may see a completely different way of working. It could be that the agentic way of working will change to something else. If it does, great! Something new to learn and to figure out. As we get older, it gets harder to stay current on some topics. However, we don\u0026rsquo;t have the luxury of our forefathers doing the same thing day in day out for our entire careers until we hit our late 60s. Honestly, I don\u0026rsquo;t know about you, but that excites me. Learning something new doesn\u0026rsquo;t mean a drastic change, it\u0026rsquo;s incremental. The AI uptake is not a difficult one. It literally is a prompter that you interact with as if you were speaking with someone else and giving specific instructions to. There are techniques to prompting and the more you do it, the better you will get at it.\nIf all else fails, then I wish you luck and hope that you have a plan b.\nHow to remain valuable Coming back to Jevons paradox, the potential for growth and opportunity still exists. However, it is not as simple as the opportunities will simply fall into your lap. There needs to be effort applied. It\u0026rsquo;s unfortunate, especially if you really don\u0026rsquo;t like change. But, that is the reality we find ourselves in. Amongst all of this, you may ask yourself during this AI era \u0026ldquo;how do I stay valuable? What does my employer value about me for them to keep me around?\u0026rdquo; It\u0026rsquo;s actually a pretty straightforward answer. What makes you valuable are several key aspects:\nDomain knowledge: Understanding your industry and how it works. Critical thinking: Does an AI model know the business and its visions like you? Doubtful. Problem solver: This will stand the test of time. Always be curious and challenge yourself. Deep understanding: AI is a tool at the end of the day. In some capacity, you need to understand what it\u0026rsquo;s doing. Don\u0026rsquo;t YOLO and hope for the best. Accountability: AI won\u0026rsquo;t take this away from you. Like the deep understanding attribute, AI is a tool that you use. If you aren\u0026rsquo;t confident in what it provides, then take another approach. If you have even one or two of these attributes, then you are still valued. Coupled with AI tooling, you\u0026rsquo;ll be more than capable of pushing forward and showing that you belong when AI uptake starts in your field or company.\nDon\u0026rsquo;t shy away from AI, lean into it, embrace it, and get prompting!\nCover image by notegpt.io\n","link":"https://pconte.tech/p/the-jevons-paradox-why-ai-wont-kill-software-engineering/","section":"post","tags":["AI","Software Engineering","Jevons Paradox","Jobs","Productivity","Democratisation"],"title":"The Jevons Paradox: Why AI Won't Kill Software Engineering"},{"body":"","link":"https://pconte.tech/categories/open-source/","section":"categories","tags":null,"title":"Open-Source"},{"body":"","link":"https://pconte.tech/tags/open-source/","section":"tags","tags":null,"title":"Open-Source"},{"body":"","link":"https://pconte.tech/tags/oss/","section":"tags","tags":null,"title":"OSS"},{"body":"","link":"https://pconte.tech/tags/tailwind/","section":"tags","tags":null,"title":"Tailwind"},{"body":"AI is rapidly evolving. This is a known fact and should come as no surprise. The next frontier will likely emerge in the agentic space, focused on fully working out how to make agents do the bidding of their overlords. As of early 2026, the latest trend is Agent Skills — a powerful mechanism that allows you to define a structured set of instructions within a given context or framework, controlling how an agent performs a specific set of tasks.\nBundled into this new AI-driven world that we live in is the software we use everyday. In the realm of software engineering, AI will happily rely on existing tools it has been trained on, knowing exactly how to write their syntax. This eliminates the need to research documentation or figure out how to structure a codebase. Where this becomes a problem is when those tools are open source projects that rely on user traffic to their websites to advertise commercial offerings. One such example is Tailwind CSS. Despite being widely popular, it is now facing the possibility of becoming abandonware due to an inability to sustainably fund its maintenance team.\nIs this a precursor to what’s to come for Open Source Software (OSS)? Will some projects simply fade away after being abandoned by their communities?\nDisclaimer: OSS doesn’t always mean free — it means the source code is open. Anyone can inspect it, modify it, redistribute it, and use it. There may be limitations depending on the license associated with the project. However, the source code remains accessible, and in most cases, you are free to do what you want with it.\nThe OSS dilemma OSS collectively struggling with funding and contribution is nothing new. Some projects manage to buck this trend through specific revenue streams, but the majority rely on communities of developers coming together to make the software work. Most of this effort is time donated out of generosity, with contributors receiving very little in return. Rarely do developers make a sustainable living purely by contributing to OSS. Instead, most treat it as a hobby — something done in the evenings or on weekends, while juggling regular jobs and other commitments. While the cause is noble and honourable, it’s not going to pay the bills.\nFundamentally and in principle, OSS is great. It allows consumers to access software that would otherwise be unavailable to them. You need only look at your own device to see how many products you use every day that you didn’t directly pay for. For me, as a macOS user, this includes applications such as:\nHomebrew Docker/Colima Golang Hugo (website framework) Kind (Kubernetes sandpit) Terraform Pike (AWS IAM policy writer) Python Drawio Multipass (Local VM runner) Obsidian (Note taking app) Rectangle (Screen management) VS code From this list, some products have commercial offerings. Docker, for example, was originally completely open source but later began commercialising certain components, such as Docker Desktop. You can still run Docker “for free” so long as you use an alternative runtime like Colima.\nThis is where the OSS dilemma emerges. On one hand, we have access to an incredible suite of tools. On the other, those who maintain and contribute to these tools receive little in return beyond personal satisfaction and a sense of community. Participation alone, however meaningful, does not translate into long-term sustainability.\nTailwind CSS’ business model To work around the broader OSS funding dilemma, companies and maintainers are often forced to get creative. In the case of Tailwind CSS, revenue is primarily driven through:\nSponsorships A premium product (Tailwind Plus) Most OSS projects adopt a similar approach, offering paid options that unlock additional features or convenience. From the earlier list, Docker offers Docker Desktop, Terraform has been steadily moving toward more restrictive free-tier options following HashiCorp’s acquisition by IBM, and both Obsidian and Rectangle provide premium tiers that unlock extra functionality.\nDespite these offerings, returning to the earlier point about AI not needing—or caring about—these monetisation mechanisms, the companies behind such tools can still struggle. In December 2025, Tailwind CSS laid off 75% of its engineering team. That figure sounds dramatic, but it’s worth remembering that it represents a percentage rather than an absolute number. In practice, this reportedly amounted to three engineers losing their jobs.\nAt face value, this may not seem groundbreaking. However, consider how much reliance we place on these tools. Without OSS, we would be nowhere near as technologically advanced as we are today, and the digital age would look markedly different.\nAn AI tool is here to get a job done. Whatever prompt it is given, it will strive to achieve that goal using the information that it has available. If the tool that it relies on works, and the pattern is repeatable rather than esoteric, it becomes trivially easy for an AI model to generate the code you need—without ever engaging with the ecosystem that sustains it.\nWhen adoption doesn’t equal growth As AI becomes a prominent part of the software creation process, it bypasses the traditional systems and mechanisms that once drove revenue. Without those pathways, some projects may simply be unsustainable and be unable to continue. This creates a strange phenomenon: adoption without growth. In most other contexts, this would be unheard of. Consider a traditional business selling cosmetics. The products are a hit — widely popular among consumers — and the business expands accordingly. Revenue climbs, the company scales, and founders and executives are well compensated as the organisation thrives. This is what we typically expect when a product succeeds. Open source breaks this assumption. Consumers often expect that a product they obtained for free will simply continue to exist. They can continue to use it, without having to pay for it, and even profit from it. This is a deeply polarising aspect of OSS. Software that was freely obtained is used to generate revenue — sometimes significant revenue — while the project enabling that success quietly struggles to survive.\nIn what logical sense is that fair? Getting something for nothing, using it for personal or commercial gain, and continuing to expect it to persist indefinitely? It feels (and is) unreasonable when examined closely. Yet this is exactly the dynamic at play — and one that AI now accelerates rather than alleviates.\nNot an isolated issue Any OSS project that relies on human interaction with its resources to continue to operate may eventually face the same fate. Tailwind CSS is simply the catalyst. As AI continues to abstract users away from documentation, communities, and project ecosystems, more OSS projects may struggle to sustain themselves and ultimately fold.\nThis should be a consideration for how we use OSS in the future. Some projects may already be in trouble without any publicity. It could be something that is happening behind the scenes. What is the most concerning here is that OSS is used in many different capacities. It is used at an individual level, at a small business level, and extends all the way to the largest corporations — often using the exact same tools. Yet corporations, collectively, are unlikely to donate back to these projects. They have little incentive to. If the product is on offer for free, why would they? Imagine how that conversation would go with the financial team when it came time to raise a purchase order. It affects the bottom line, and if there is anything organisations always need more of, it\u0026rsquo;s money!\nTurning point and the future of OSS Tailwind CSS faces an uncertain future. Further reports are yet to emerge on how it is tracking financially or what its future holds. Sources suggest that some larger corporations and individuals who rely on Tailwind CSS have stepped forward to offer donations. However, there are concerns about how much is actually being raised and whether it is sufficient to pull Tailwind out of its current financial rut. Time will tell how it all plays out — and whether the internet will eventually need another CSS framework in the future when doing code refactors. Hopefully, one that can monetise itself effectively and remain operational.\nSo what does this mean for the future of OSS? It should serve as a warning. Not all projects are killing it, and some maintenance teams may have a heavier dependency on those projects than others. We all need to eat. Skilled software engineers are in demand — not those who simply “vibe code”, but the actual ones who nowadays leverage AI to make their code better and tackle their workload efficiently.\nOSS will continue to be as it was. In the event that a maintainer of a major project is unable to continue, the project either finds another one or it stops being supported. It\u0026rsquo;s happened before, and it will happen again. A recent example of this is the Ingress NGINX project. As the saying goes for the World of Warcraft geeks — No king rules forever.\nCover image by Artlist.io\n","link":"https://pconte.tech/p/tailwind-css-a-warning-for-open-source-projects-in-the-age-of-ai/","section":"post","tags":["Tailwind","Open-source","AI","OSS"],"title":"Tailwind CSS: A warning for open source projects in the age of AI"},{"body":"","link":"https://pconte.tech/categories/architecture/","section":"categories","tags":null,"title":"Architecture"},{"body":"","link":"https://pconte.tech/categories/aws/","section":"categories","tags":null,"title":"AWS"},{"body":"","link":"https://pconte.tech/tags/cost-analysis/","section":"tags","tags":null,"title":"Cost Analysis"},{"body":"Introduction AWS networking is fairly straightforward in a small setup. As a singular environment, you will generally have a single VPC that consists of:\nSubnets Route tables Network ACLs (NACLs) Security groups An Internet Gateway (IGW) NAT Gateway(s) There are other components, and even some of the ones mentioned here may not be required. You might have a single subnet for all of your resources. Likewise, a NAT Gateway may not even be necessary (this is rare — and anyone exposing private workloads to the internet unnecessarily is not following best practice).\nBut what about in more sophisticated setups, where you have multiple isolated networks in the form of several VPCs across different AWS accounts? You may need to introduce a shared services layer — an isolated VPC (or multiple, depending on your use case) that houses applications used to support your environment. Rather than duplicating these components inside each VPC, we share them (hence the name). To share these components, the VPCs need to be interconnected. AWS provides a service called Transit Gateway (TGW) to achieve exactly that, at scale.\nBuilding on the shared services concept, NAT Gateways provide a solution that allows private subnets to connect to the internet for outbound (egress) traffic. They are deployed into public subnets (with a default route to an IGW) so that resources can route through the NAT Gateway to access the internet. NAT Gateways aren’t strictly bound to the VPC they are deployed in — you can use them across different VPCs if you choose, by leveraging a TGW.\nWith all of this context in mind, at what point does it make sense to use a NAT Gateway in each VPC (decentralised egress) versus using a TGW to route all internet traffic through a single VPC and set of NAT Gateways (centralised egress)? Which option is more cost-effective? Let’s find out.\nArchitecture: Centralised vs decentralised Let’s begin by outlining each of the solutions and what they look like architecturally.\nCentralised VPC count: 4 Workload VPCs: 3 Egress VPC: 1 Transit Gateway count: 1 Transit Gateway attachments: 4 Transit Gateway route tables: 1 NAT Gateway count: 2 (both deployed into the Egress VPC) Each VPC will be associated with a single Transit Gateway (TGW) route table and propagate its routes accordingly. A default route will be configured to point to the egress VPC, enabling a centralised egress pattern.\nEach VPC will be created in a separate AWS account, except for the egress VPC, which (along with the TGW) will reside in a dedicated networking account. The TGW will be shared via AWS Resource Access Manager (RAM) to each respective AWS account, allowing TGW attachments to be created for each VPC.\nThis is what the architecture looks like: Decentralised VPC count: 3 (Workload VPCs only) Transit Gateway count: 1 Transit Gateway attachments: 3 Transit Gateway route tables: 1 NAT Gateway count: 6 (2 in each workload VPC) Each VPC will be associated with a single TGW route table and will propagate its routes accordingly. This route table will not contain a default route, as traffic will exit locally via each VPCs NAT Gateways before reaching the TGW.\nEach VPC will be created in separate AWS accounts. The TGW will again be created in the networking account and RAM shared to each AWS account to allow for TGW attachments per VPC.\nThis is what the architecture looks like: Now that the architectures are defined, let’s dig deeper into the pricing of each component.\nPricing models NAT Gateways NAT Gateways have a simple pricing model. You pay for two main things:\nHourly cost per NAT Gateway Data processed (in GB) by the NAT Gateway The source or destination of the traffic is irrelevant — if the data passes through the NAT Gateway, you\u0026rsquo;re paying for it.\nIn addition to NAT Gateway costs, there are data transfer fees for services like EC2. This includes:\nTraffic going out to the internet Traffic sent to other AWS regions Traffic sent between Availability Zones (AZs) within the same region It’s also worth mentioning that VPCs themselves are free. While components inside a VPC (like NAT Gateways) may incur costs, the VPC construct has no cost on its own. So for this comparison, we’ll only factor in the pricing for NAT Gateways.\nTransit Gateways Transit Gateways follow a similar pricing model to NAT Gateways. You pay for:\nHourly cost per Transit Gateway attachment Data processed (in GB) by the Transit Gateway As with NAT Gateways, data transfer fees for services like EC2 still apply and should be considered — especially for inter-AZ or inter-region traffic.\nCost breakdown To calculate actual costs, we need to use the pricing from an AWS region. For this exercise, we’ll use the AWS Sydney region (ap-southeast-2). Based on this region, the pricing is as follows:\nNAT Gateway Hourly fee: $0.059 Per GB of data processed: $0.059 Transit Gateway: Hourly fee (per attachment): $0.07 Per GB of data processed: $0.02 For both the centralised and decentralised solutions already outlined, we’ll assume 100 GB of data processed in total. We’ll also assume a billing duration of 30 days (720 hours) for the hourly costs.\nAlthough both solutions will incur data transfer fees (e.g. to the internet, to other AWS regions, or between AZs within a region), these are identical in both cases. As such, we’ve excluded them from this comparison to focus only on the NAT and Transit Gateway pricing.\nCentralised cost breakdown Component Cost NAT Gateway 1 (hourly fee) $42.48 NAT Gateway 2 (hourly fee) $42.48 NAT Gateway (data processing) $5.90 Transit Gateway (Egress VPC attachment) $50.40 Transit Gateway (Workload A VPC attachment) $50.40 Transit Gateway (Workload B VPC attachment) $50.40 Transit Gateway (Workload C VPC attachment) $50.40 Transit Gateway (data processing) $2 Total $294.46 Decentralised cost breakdown Component Cost NAT Gateway 1 (hourly fee) $42.48 NAT Gateway 2 (hourly fee) $42.48 NAT Gateway 3 (hourly fee) $42.48 NAT Gateway 4 (hourly fee) $42.48 NAT Gateway 5 (hourly fee) $42.48 NAT Gateway 6 (hourly fee) $42.48 NAT Gateway (data processing) $5.90 Transit Gateway (Workload A VPC attachment) $50.40 Transit Gateway (Workload B VPC attachment) $50.40 Transit Gateway (Workload C VPC attachment) $50.40 Transit Gateway (data processing) $2 Total $413.98 Findings With the findings in tow, it\u0026rsquo;s clear which solution is more cost-effective based on the defined setup. The centralised egress solution comes out ahead in terms of cost when compared to the decentralised one — as long as the assumptions hold.\nHowever, there are edge cases worth exploring. Also, note that we used a \u0026ldquo;magic number\u0026rdquo; of 6 NAT Gateways in the decentralised setup — something we’ll expand on shortly.\nWhat if fewer VPCs needed egress? Suppose only one of the three workload VPCs in the decentralised solution actually required egress access (and therefore NAT Gateways). If you removed 4 of the 6 NAT Gateways, your total would drop to $244.06 — cheaper than the centralised solution.\nWhat If You Removed the Transit Gateway? Now imagine removing the Transit Gateway from the decentralised solution entirely, and each of the three VPCs had their own local NAT Gateways, but no interconnection. In that case, the total cost would come to $260.78 — not as low as the previous example, but still cheaper than the centralised solution (at $294.46).\nWhy We Used 3 VPCs as a Baseline The reason we compared three workload VPCs and 6 NAT Gateways is that this configuration represents a cost-efficiency threshold. Beyond this point, the decentralised approach starts to suffer from diminishing returns.\nWhile it may seem obvious to adopt a centralised solution, there\u0026rsquo;s a case to be made for starting with decentralised egress — especially in early-stage AWS environments that aren’t yet interconnected. If the VPCs remain isolated, decentralised egress might be more cost-effective. But as soon as inter-VPC connectivity is required, the decentralised model becomes significantly less economical.\nAdditional cost scenarios Here are some expanded scenarios to help illustrate the cost impact at scale:\nScenario Total Cost Decentralised: 4 VPCs, 8 NAT Gateways, 0 TGW $345.74 Centralised: 4 VPCs + 1 egress VPC, 2 NAT Gateways, 5 TGW attachments $344.86 Decentralised: 5 VPCs, 10 NAT Gateways, 0 TGW $430.70 Centralised: 5 VPCs + 1 egress VPC, 2 NAT Gateways, 6 TGW attachments $395.26 As shown above, once you pass three VPCs, the centralised model quickly becomes more attractive from a cost perspective.\nCentralised solution benefits While the primary focus of this blog is cost, not everything comes down to price. Ultimately, the real question is: what are you willing to pay for best practice and a secure, scalable setup?\nAWS provides several services that enhance security at the networking layer. Two key examples include:\nAWS Network Firewall – a fully managed stateful firewall service Gateway Load Balancer (GWLB) – supports third-party firewalls in a “bump-in-the-wire” architecture Both of these services are designed to operate in a centralised model, enabling consistent inspection of traffic — whether it\u0026rsquo;s north/south (in and out of the AWS network) or east/west (between VPCs/subnets). Any traffic that bypasses these centralised inspection points risks being unauthorised or even malicious. Without a centralised architecture, enforcing an inspection solution across multiple VPCs becomes near impossible.\nIf you needed any more reasons to lean toward a centralised model — regardless of cost — the ability to integrate services like AWS Network Firewall and Gateway Load Balancer should be near the top of the list.\nConclusion Egress traffic in AWS must traverse some kind of gateway to reach the internet. For private subnets, this means using a NAT Gateway. As we’ve explored, NAT Gateways can either be local to each VPC or located in a centralised egress VPC, connected via a Transit Gateway.\nCentralised solutions work best at scale and offer stronger alignment with AWS’s security services. Decentralised solutions, on the other hand, are often more suitable for smaller environments — either early in their cloud journey or intentionally minimal in scope.\nThe next time you\u0026rsquo;re designing how traffic should leave your AWS environment, consider the long-term direction, cost implications, security posture, and — most importantly — what the environment needs to function effectively.\nCover image generated by DeepAI\n","link":"https://pconte.tech/p/designing-egress-in-aws/","section":"post","tags":["Transit Gateway","NAT Gateway","Egress","Network Security","Cost analysis"],"title":"Designing Egress in AWS"},{"body":"","link":"https://pconte.tech/tags/egress/","section":"tags","tags":null,"title":"Egress"},{"body":"","link":"https://pconte.tech/tags/nat-gateway/","section":"tags","tags":null,"title":"NAT Gateway"},{"body":"","link":"https://pconte.tech/tags/network-security/","section":"tags","tags":null,"title":"Network Security"},{"body":"","link":"https://pconte.tech/categories/networking/","section":"categories","tags":null,"title":"Networking"},{"body":"","link":"https://pconte.tech/tags/transit-gateway/","section":"tags","tags":null,"title":"Transit Gateway"},{"body":"","link":"https://pconte.tech/categories/design/","section":"categories","tags":null,"title":"Design"},{"body":"","link":"https://pconte.tech/tags/design-principles/","section":"tags","tags":null,"title":"Design Principles"},{"body":"","link":"https://pconte.tech/tags/over-engineering/","section":"tags","tags":null,"title":"Over-Engineering"},{"body":"","link":"https://pconte.tech/tags/perfect-vs-practical/","section":"tags","tags":null,"title":"Perfect vs Practical"},{"body":"Introduction Designing IT solutions is a challenging task. Not only do you need to take several factors into consideration, but you also need to understand the lifecycle of what you’re designing. Questions will inevitably pop into your head, like:\nHow long does this solution need to last? Is it going to be perpetual? How do we handle high availability and disaster recovery? When will I know it\u0026rsquo;s complete? That last point—when will I know it\u0026rsquo;s complete?—can be ambiguous. Does it mean the solution is fully fleshed out and working at the desired end state? Or does it mean it\u0026rsquo;s ready once a Minimum Viable Product (MVP) has been constructed?\nIf the solution is too simple, it may lack features or fail to scale. But if it’s too complex—over-engineered—it might introduce unexpected bugs and hurt not just our credibility, but also the brand we represent, especially in a corporate context. And beyond the bugs, what about the cost of building that solution? Our time? Money? Resources? All potentially wasted on something that doesn’t deliver a meaningful return on investment.\nIt’s a conundrum, no doubt. But there are frameworks and considerations that help you draw the line and confidently mark a solution as done based on criteria.\nUnderstanding a solution One of the first fundamental skills that you need to understand as a Consultant or anyone in a role that involves designing or architecting solutions—is the ability to understand the what and the why:\nWhat are we doing? What are we building? What is it? What will it be? Once we understand that what, we move on to the why:\nWhy are we doing this? Why are we building this? Why do we need to include x, y and z? Why is this or that a good idea? All of those what and why questions can be summarised in a single word: requirements. Requirements are the driving force behind the rationale. They help shape what the solution will look like and give context to the decisions made along the way. They set the direction—establishing goals, coordinating efforts across teams, and managing expectations for stakeholders. From a commercial perspective, requirements are assessed and translated into elements such as definition of done and/or acceptance criteria. These elements are then used in commercial agreements like a Statement of Work (SoW) to provide clear and concise deliverables for all parties involved.\nWhen we understand the requirements of what we’re setting out to do, we have structure. That structure becomes the foundation for a plan—where ideas take shape and strategy begins to form. As you become more proficient in your craft—whether it’s software, infrastructure, or something else—you’ll begin to recognise patterns. You’ll recall what worked well and what didn’t in previous experiences. Armed with that insight, you’ll feel more confident when similar situations arise, and better equipped to act early—before issues have a chance to fester.\nThe definition of complete Now comes the tricky part of this process: What defines a solution as complete?\nIs it something that we can measure? Does it relate to its run cost? Can it handle the load we need it to? Will it accumulate technical debt? We do have frameworks and tools to help answer these questions. In the previous section on understanding a solution, we mentioned the definition of done and acceptance criteria. Depending on how mature the environment and organisation are, these could be loosely defined or meticulously detailed. By using these elements, we can clearly describe what a “complete” solution looks like—aligned with what we’re trying to achieve now.\nEven though we use the term “complete”, it doesn’t always mean the end state. More often, it marks a meaningful checkpoint. The future state will continue to evolve—just as the broader IT landscape constantly shifts.\nA definition of done may reflect a simple, even traditional, solution. Solutions don’t need to be extravagant if they fulfill the basic requirements. There’s nothing wrong with doing things the old-fashioned way. Take mainframes, for example. You might think of them as legacy tech from the 1960s—but would it surprise you to know that many major corporations across sectors like finance, government, and healthcare still rely on mainframes today to process transactions? Mainframes continue to hold relevance because of their unique capabilities and the critical roles they play in these industries. Could they be replaced by modern stacks like serverless architectures? Probably. Is it a simple task? Absolutely not.\nThe mainframe example highlights two key principles:\nIf it isn’t broken, don’t fix it — or in other words, if it works, don’t change it. Old technology doesn’t automatically mean obsolete — in fact, as older generations retire, we might even see a kind of renaissance for legacy technologies like mainframes. At one point in history, mainframes were considered the north star of computing. Fast forward to today, and our modern-day north stars might be serverless platforms that run only your code—or perhaps AI-powered observability systems that proactively detect anomalies.\nTechnology doesn’t stand still. It evolves rapidly. Today, we’re seeing explosive growth in AI, particularly with agentic models that leverage Model Context Protocol (MCP) servers.\nSo when it comes to defining what makes a solution \u0026ldquo;complete,\u0026rdquo; remember these quick tidbits:\nIt’s fit for purpose. It doesn’t need to last forever—just for today, tomorrow, and the near future. Solutions will always evolve. It will scale within reason. If you’re expecting millions of requests per second, architect accordingly. But if you\u0026rsquo;re only handling a few per second, you don’t need a massive data platform with all the bells and whistles that might cost thousands per month to run. It will work. This is the core of it all. “Working” might mean different things to different people, but ultimately, the solution behaves as intended and delivers on its purpose. Over-engineering and its ramifications So what happens when we go to the other extreme? Rather than stopping at our definition of done, we push way past it and engineer the hell out of a solution. It’s amazing! It’s something to behold!\n…Or is it?\nHow far down the rabbit hole did you have to go to get there? And ultimately—what was the cost?\nOver-engineering is contextual. When it does happen, it can manifest in different forms depending on the solution. One of the worst forms is trying to account for every possible future use case—a “just in case” mindset. Building a solution to handle everything that might happen in the future can stifle progress. It can halt or delay the project until there is mutual resolution amongst stakeholders, all while delaying progress to the end goal. In situations like this, I often use the saying: “the juice isn’t worth the squeeze.” In other words, to achieve X, we need to do Y—and Y just isn’t worth the investment of our time, resources, or mental energy.\nAnother form of over-engineering is adding unnecessary complexity. The maturity of a solution must be factored in when architecting. Introducing advanced complexity to a system that’s not ready for it can be wasteful, or even damaging. Take a startup, for example. Let’s say their core revenue-driving product is a piece of software. Right now, that software runs on a single PC under someone’s desk. Is it elegant? No. Does it work for now? Actually, yes—in a very non-ideal way.\nIf that same startup tries to launch into a cutting-edge, serverless cloud architecture with auto-scaling, CI/CD pipelines, and bleeding-edge automation—but has no current need for it—that effort would be a catastrophe. The resources required to build and support such a setup would likely never see a return, especially if the startup is still finding product-market fit or struggling with cash flow. In fact, they might run out of steam entirely and fold before realising their goals.\nA solution shouldn’t be too top-heavy at the start. By that, I mean: don’t add features or components that don’t bring actual value in the near term. Later—once things stabilize and there’s a clear path forward—it might make sense to revisit and layer in those “nice to have” features. But early on, they often just weigh you down.\nReturn on Investment (ROI) and building momentum After we get through the rigorous process of vetting the solution using the mechanisms already mentioned, we need to shift into a mindset that focuses on vision—the long-term outlook for the solution. As part of this vision, we must consider how we extract value over time and achieve a solid return on investment (ROI). But ROI isn’t always about money. There are other forms of currency we “spend” to make a solution functional and successful. These include:\nTime Effort On-going support Business integration Let’s start with time. It’s one of our most precious resources—yet most of us (myself included) never seem to have enough of it. In the digital age, it’s easy to jump from watching Judge Judy on YouTube to checking sports results, reading the latest tariff news, playing a video game, or falling into a social media rabbit hole. There’s always something waiting to eat into our time.\nSo, when we invest time into a solution, it should give us time back. The return should come in the form of efficiency or automation. This is especially true when adopting DevOps methodologies, where the whole premise is to automate as much of your role as possible—freeing you up for higher-value tasks.\nAnother often-overlooked factor is the longevity of the solution and what ongoing support and maintenance will look like. Simple systems might be seen as ancient by today’s standards—but they can also be the easiest to maintain, debug, and enhance. A “good enough” solution today often beats a “perfect” one six months from now.\nA solution that is well-vetted, tested, iterated upon, intuitive, and clearly defined delivers strong ROI—not just for development teams, but also for project managers, business stakeholders, and end users. When more people begin interacting with the solution, momentum builds. Feedback loops form, giving valuable insight into what to improve or prioritise next.\nThis is how momentum turns into progress. This is how “good enough” evolves into great.\nConclusion The next time you\u0026rsquo;re designing a solution—or playing a role in shaping one—consider what’s practical to get it working now, versus what’s “perfect” but loaded with nice-to-have features that may not add much value.\nDon’t get stuck in the weeds and chase those rabbits too deep into those holes! While it can be fun to experiment and theory-craft, a good engineer or architect knows when they\u0026rsquo;ve gone deep enough to achieve a solid result for a reasonable amount of effort. In the end, completing a solution up until a point isn’t settling. It\u0026rsquo;s being strategic.\nCover image by dix sept on Unsplash\n","link":"https://pconte.tech/p/perfect-vs-practical-how-to-know-when-an-it-solution-is-ready/","section":"post","tags":["Perfect vs Practical","Over-Engineering","Design principles","Solution completeness","ROI in tech"],"title":"Perfect vs Practical: How to know when an IT Solution is ready"},{"body":"","link":"https://pconte.tech/tags/roi-in-tech/","section":"tags","tags":null,"title":"ROI in Tech"},{"body":"","link":"https://pconte.tech/tags/solution-completeness/","section":"tags","tags":null,"title":"Solution Completeness"},{"body":"","link":"https://pconte.tech/categories/strategy/","section":"categories","tags":null,"title":"Strategy"},{"body":" Intro Hey, I\u0026rsquo;m Patrick. I\u0026rsquo;m a technology professional specialising in cloud infrastructure engineering and consulting. With over 15 years of experience, I\u0026rsquo;ve seen and experienced the significant shift from on-prem to public cloud and now the introduction of AI into basically everything.\nWhat I share here is mostly content that I think would be insightful and assist those who would like to know more about something which I have expertise in.\nWhat are you passionate about? Technology, its capabilities and sharing my thoughts/ideas. I love being able to have lengthy conversations about my experiences, learning about advancements, teaching others and sharing ideas. Tech is my forte. It\u0026rsquo;s something that has been with me ever since I was a young boy growing up in the 90s when the internet was something you accessed via a dial-up modem and got a 56k connection. Yes, queue that infamous dial-up modem sound 🔉\nWhat am I going to see here? I really just want to carve out a space that allows me to interact with a wider audience for the purposes of:\nEducation Ideas sharing Knowledge transfer Upskilling Having experienced IT and tech the way that I did, I was able to get a look at what it was like when we ran most of our server environments in an on-premise setting. Now that cloud is much more prevalent, those on-premise experiences translate to how we do it in the cloud, even though those fundamental technologies still exist under the hood. Whilst they are obstructed, they are still important to learn and understand. This may end up being a two-way street. I\u0026rsquo;d love to learn more from you as well if we share a common interest!\nWhere are you working? As of May 2026, I am working as a Senior Cloud Engineer for Insignia Financial. I decided it was time to leave consulting to pursue an internal gig to challenge myself technically. While consulting offered this, it didn\u0026rsquo;t offer it the way I wanted. Let\u0026rsquo;s see where this next role takes me!\nHow can I contact you? Feel free to hit me up on LinkedIn\nIs there anyway to support your work? Yes! Blogging is a passion project of mine that I do when I get ideas. If it gets solid traction, and I\u0026rsquo;m able to dedicate more time to it, I\u0026rsquo;d love to produce more content. If you\u0026rsquo;d like to contribute to that journey, feel free:\nhttps://buymeacoffee.com/patconte\n","link":"https://pconte.tech/about/","section":"page","tags":null,"title":"About"},{"body":" GitHub — the world\u0026rsquo;s largest software development platform. Tabler Icons — a great little assets website to find icons. ","link":"https://pconte.tech/links/","section":"page","tags":null,"title":"Links"},{"body":"","link":"https://pconte.tech/page/","section":"page","tags":null,"title":"Pages"},{"body":"","link":"https://pconte.tech/series/","section":"series","tags":null,"title":"Series"}]