“A lot of what has been described as innovation as technical advancement in the last few years was actually more about maximizing profit or conquering intellectual frontiers,” says David Heinemeier Hansson, the creator of the Ruby on Rails framework and co-founder of 37 Signals. DHH, a bold contrarian and a commentator on the tech industry, spoke at the We Are Developers World Congress in Berlin.

Of course, he was talking about the uncritical use of cloud technology, omnipresent subscription models, and the rising complexity of developer tools.

Leaving the cloud

DHH became notorious when, in the spring of 2023, he announced his companies were “leaving the cloud” to save millions of dollars. They will own their data centers instead of renting them from cloud providers:

By moving away from the cloud, we predict our savings to 1,5 million dollars a year. Consider whether you have a service that really benefits from constantly scaling the capacity up and down.

Don’t just stay in the cloud because of the hype!

Software is rented, not owned

He feels the same about the prevailing model of renting software or Software-as-a-Service (SaaS). That’s why 37signals has decided to launch their two products, Campfire and Writebook, with the business model opposite of the software subscription model – ONCE. As he explained in the announcement:

Something happened to business software.You used to pay for it once, install it, and run it. Whether on someone’s computer, or a server for everyone, it felt like you owned it. And you did.

Today, most software is a service. Not owned, but rented. Buying it enters you into a perpetual landlord–tenant agreement. Every month you pay for essentially the same thing you had last month. And if you stop paying, the software stops working. Boom, you’re evicted.

“The ‘Once’ model offers a clear, upfront cost without the ongoing financial burden. This transparency and simplicity can be very appealing,” DHH noted.

How do you scale your company if your customers only pay once for your product, and most of them don’t ever buy the new version? Hear more from DHH in our sister podcast, ScaleUp&Up.

Ruby on Rails is interesting again

DHH also reflected on the early days of Rails and its impact on tech startups. He recounted how, in 2007, Rails surged in popularity, with startups like Shopify, GitHub, and SoundCloud adopting the framework:

 “The reason they were picking Rails at the time is quite similar to why we’re seeing a resurgence in interest now. Many startups then emerged from a period of economic downturn and limited capital, much like today’s scenario with venture capital fluctuations and layoffs.”

He remarked that tech has moved from caring deeply about productivity and building things efficiently with small teams to a phase where money was abundant, and companies could hire more people to throw at problems:

We need to lower barriers for solo developers and small teams. If we make the barrier to entry so high that the only way to start building something is to raise a lot of money and hire a bunch of specialists, fewer ideas will get the opportunity to prosper.

He also addressed the challenges of complexity in modern web development and how it contrasts with earlier, more accessible frameworks like Rails:

We’ve tried to keep the vision of one developer being able to understand the whole system.

Make things simple again

DHH acknowledged the significant advancements and enthusiasm around JavaScript single-page applications:

“The problem with new ideas is that in an expansionist mode, especially with ideas from places like Facebook with React, the focus isn’t on making things simple — it’s about conquering new intellectual frontiers.” 

There is also an emphasized need, fueled partly by the shift to remote work, for simplicity and efficiency in development tools. He said that he was excited by the combination of technological and economic forces that enable small teams to build MVPs without needing extensive resources.

The post DHH: Make software simple again appeared first on ShiftMag.

“The tooling or framework is not going to have the impact on 2024 that I think the stress, pressures, and eventual burnout are going to have on developers in the cloud-native world in 2024”, says Eric D. Schabell, Director of Technical Marketing & Evangelism at Chronosphere, a cloud-native observability tool.

He believes this will lead not only to unhappy developers but also fuel career movements as they seek more satisfying and happy workplaces in 2024.

Eric has also published his predictions for emerging trends in 2024 on his blog, and this is his list of the most important trends for the year.

Prioritizing mental health

In his blog post, Eric highlighted several trends he believes will shape the industry in 2024. One of them is the focus on cloud-native burnout.

Every role, from Site Reliability Engineers (SREs), DevOps, engineers, developers, and managing any part of the cloud-native engineering experience within an organization. They all resonated with this being the number one theme out there.

According to research in a 2023 Cloud Native Observability Report, which Schabel refers to in his blog post, and which surveyed over 500 engineers and developers:

• They spend 10 hours on average – a quarter of their 40-hour work week, trying to triage and understand incidents
• 88% reporting the amount of time spent on issues negatively impacts them and their careers
• 39% admit they are frequently stressed out
• 22% said they want to quit

Because of that, Eric’s prediction is that the attention this topic got in 2023 will expand and deepen into all areas where organizations are trying to grow their cloud-native footprints:

“In 2024 we will hear more about burnout-related stress, hear more ideas on how to solve it, and see it become one of the biggest topics of conversation at events, online, and at the coffee machine”.

High stress = high turnover rate

The stress and burn-out discussed in the first prediction are expected to lead to increased career movement, thinks Schabell. High levels of stress, burnout, and pressures in cloud-native organizations contribute to high turnover rates.

I predict a surge of career movement. Over 25% of current tech roles will take the plunge and try to find fulfillment in now roles, new organizations and take on new opportunities.

Focus on cloud-native cost management

Since its inception in early 2019 and subsequent integration into the Linux Foundation in 2020, the FinOps Foundation has evolved into a crucial entity for both cloud-native and cloud-utilizing organizations. Throughout 2022 and 2023, organizations have increasingly recognized the necessity of deriving value from every dollar spent on cloud-native services.

Along these lines the FinOps Foundation has become the central gathering place for practitioners in the FinOps role across all kinds of organizations. 

His prediction is that the continued growth seen in the field of FinOps in 2023 in cloud-native organizations will evolve in 2024 into a permanent value-add for more and more organizations.

“CIOs, CFOs, and CTOs are going to lean more in 2024 on the FinOps roles, processes, and education to manage their cloud-native spend to ensure the value per dollar spent continues to have impact on their cloud-native investments”, says Schabell.

Read more:
What is developer burnout and how to prevent it
How to implement FinOps

The post 2024 will be the year of cloud-native burnout appeared first on ShiftMag.

With a career spanning over 25 years, Dino Esposito became synonymous with technological education. He published 20 books and over 1,000 articles, so it’s an understatement to say that his legacy in the technology world is priceless.

He skillfully navigated the transition from MFC to .NET, promoting innovation even when cloud was just a meteorological term. His visionary approach led to early versions of what we recognize today as cloud photo storage, long before the age of Google Photos.

Dino is currently the technical director at Crionet. He is the brain behind the platforms for professional tennis and Padel tournaments. In addition, he is a software development consultant at KBMS Data Force, a data-oriented company in the healthcare sector, with a portfolio of solutions for patient monitoring and digital therapy, which, among others, has been installed at the Gemelli Hospital in the Vatican.

We had the privilege to talk with Dino about the tech industry from his youth and today, whether fundamentals or specific technologies are more important, and he shared his advice for developers regarding AI.

“30 years ago we coded in digital caves”

Dino: It was a much more closed environment with a few big players to choose from, whether Microsoft, IBM, or Sun. Fascinated by Bill Gates, I always wanted to go with Microsoft. Thirty years ago, in the early 1990s, it was like the stone age. My first company was a real startup by today’s standards, and we were doing digital imaging in what was later called “cloud” when the JPEG format was emerging.

Today, it is a jungle. And that could be an interesting parallel. Like early humans, we used to code in digital caves, relying on hunting and gathering information for sustenance. We crafted tools and weapons from C, Assembly, and C++, with convoluted language-specific SDK to run a simple database query.

Our existence as developers was closely tied to our passion and attitude, with limited technology and community structures. Today, it’s more like a jungle. A jungle is a lush ecosystem rich in diverse forms of technology. Towering companies with broad cloud environments create a continuous, shaded tunneled vision. Various products and platforms thrive beneath to give birth to an array of wildlife software, from exotic technologies to large frameworks. The tech industry is today a neat biodiversity hotspot. What after the jungle? Hopefully, urbanization.

Fundamentals or specific technologies?

Dino: I graduated in 1990 from what, at the time, was one of the few places in Europe to study computer science. The degree course was not even set up in its own Computer Science faculty. It was a leg of the more classical faculty of Mathematics, Physics, and Natural Sciences. Right or wrong, our education was centered on computer science’s mathematical aspects–the logic behind programming languages and grammar, engineering principles, and algorithms.

I graduated without ever approaching a computer, except typing a few words in an IBM terminal. So, my obvious first answer can only be “fundamentals.” I never got back to fundamentals, though, after my degree – with very few occasional exceptions when I switched to a significantly new branch of software.

About his title, “A Cloud Visionary”

Dino: I never believed in the cloud as a salvific technology. Remember, the cloud started gaining ground around 2008 (Azure was announced at that time), right after the Lehman Brothers crash, when the entire IT world (and not just that) was about to sink with money physically drying out.

People wanted to believe in the new “cloud” as a supernatural entity capable of bringing back jobs and money. I never embraced this salvific vision of the cloud. With a small team of five people, we used to save/download pictures from the cloud back in 1995, except we didn’t call it “cloud.”

Today, the cloud is everywhere as an effective support for applications like real clouds. I don’t live in the clouds; I live on the ground and love clouds. I have never seen the power of the cloud at some point. Instead, I naturally started leveraging it. Today, I don’t believe at all in what many call cloud-native apps also because aside from names, I don’t see a substantial difference with cloud-b.

Advice for developers on AI

Dino: I have two favorite quotes about AI that emerged naturally out of presentations. One is “AI is just software”. The other is “in the beginning is only randomness; in the end is only a matter of error.” 

AI is software, period. As software, it gets numbers and returns numbers. All concerns the media emphasize are the outcome of software pipelines that may be set up to make decisions. AI is a black box that returns a number – what is done with that number is the same “other” problem we still face today.

What if we set an algorithm that returns 1 if a button is pressed on a number of even milliseconds? What if we link getting 1 to launching a nuclear weapon? Is it all because the algorithm returned 1 on an even millisecond? This said, in the past year, we assisted in a “real” giant leap. Machine learning alone is not sufficient to change the face of the world–in fact, when I graduated in 1990, some of my colleagues defended their thesis on neural networks!

The real breakthrough is LLMs. For one reason – they shorten the communication between humans and software by bringing software closer to the human way of communicating. It’s phenomenal statistics, but it cut short the distance between human wording and formal reasoning of software. Developers still sit in the middle doing the invisible work of connecting humans and software – at a higher level of abstraction, though.

LLMs open a whole new world of business opportunities for developers, but wait – they only apparently are easy opportunities to seize. Study and trial-and-error are FUNDAMENTAL. Beware those (mostly marketers and influencers) who make it too easy.

About his new book

Dino: Unfortunately, it’s only a bit more than a project. I have a few chapters written, but no publishers are interested. My idea is to go through the history of software since the days in which formal reasoning was devised (back to the Middle Ages and Renaissance) and then turned into mathematical reality (1930s) and finally engineered (1950s). All in all, software as we know it today is the waste product of much more ambitious research–automating human reasoning.

The AI we experience today is a fake in this regard. These are phenomenal statistics, but they are far from thinking machines. Readily available computers of today have power in the order of gigs/hertz. The human brain is slow in the number of operations per second (around 100/sec), but it has a massive set of connections parallelizable operations. In the end, it’s about nine orders of magnitude of difference.

The day computers could reason at the speed of the human brains, it will be a different world. And maybe computers could fall in love. Why not?

The post Dino Esposito: AI is software, period. appeared first on ShiftMag.

It all started back in 1991 with a Commodore 64 computer and some books. Darko would type in some code from the books, and “things were happening on the screen”. At some point later he got immersed in the world of video games, the internet, operating systems, and programming, but his dream job was – being an IT support person.

My boyhood dream was being that person that gets in the car in the middle of the night and fixes computers.

That dream did come true for him but in a different way. Darko started at Amazon as a Premium Support Engineer for AWS, but now he does something completely different: live-streaming on Twitch.

Developer Advocates do more than just talk at conferences

You currently work at Amazon as a Senior Developer Advocate. How did you get to this company, and what was the journey like?

Darko: Amazon came to me by chance. I got an invitation from their recruiters via LinkedIn. After a few conversations, I got the opportunity to work with them and accepted it with open arms. Like most people at AWS, I started in a junior position. Actually, I didn’t do what I’m doing now. I started as a Premium Support Engineer. And in terms of progression, I began as Level 4, and I’m already (almost) Level 7, which I consider a great personal success.

I came to Amazon with quite a bit of knowledge about AWS, but I got six months of training and preparation to get to that certain required level. Which I was thrilled about and needed.

Tell us more about your position. What does a Developer Advocate do at Amazon?

Darko: 

The job of a Developer Advocate- former Technical Evangelist, is much more than just running around conferences and giving presentations.

Many things are done in the background related to the organization and curation of content. For example, people in my position do the entire selection and processing of content/speakers for our significant summits and conferences. But one of the nice things about this role is that it’s different for almost everyone. In my position, I am focused on live-streaming content.

I spend most of my time working on strategy, organization, and execution of Live Streams for AWS (I have at least two weekly episodes on the AWS Twitch channel). And after all those streams and events, I have to redirect any feedback to the right people at AWS.

Amazon is a big company, but it’s more like many small startups inside one big organization. So That allows us relative freedom in decisions about what we will do and how we will do it.

Learn Python. It Just Works.

What is your programming language of choice?

Darko: Regarding programming languages, it depends on what I try to do. Mostly, these days, you will see me fiddle around with Python. Why Python? Well, it Just Works. All jokes aside, I think Python is an excellent language for people who do not write code daily.

Python as a language is easy to get into, easy to do what you need it to do, and has a fantastic community. Besides Python, I use JavaScript for most of my infrastructure development (with Infrastructure as Code tools such as AWS CDK) and for some front-end stuff. When not using any of these languages, I stick to C++, C, and Lua. Those languages are close to my heart, and I enjoy using them.

What would you say is the most popular programming language currently, and why?

Darko: Instead of saying what are the most popular languages, let me change the question – “What are the most important languages?”. In my humble opinion (and remember, I am not a developer, so I have no reputation to defend), the most important languages to learn in 2023 are Python and JavaScript. Okay – why this? Simple: With the ever-growing expansion of AI/ML, Python has become the de facto language of AI/ML developers. Most AI/ML projects are done using Jupyter Notebooks and Python.

Hence, if you want to do anything in that space (and I hope you are), Python should be your language of choice. As for JavaScript, well, anything that is done today on the web is mainly done using one or more JavaScript frameworks. It is definitely the thing that moves the web, some phone apps, and more.

So, no matter what you think about languages such as Java, Rust, or GoLang – as it stands now, I believe JavaScript and Python are the most essential languages.

Kubernetes on a Tandy portable computer, cloud infrastructure on Commodore 64…why?

You used a 1986 Tandy portable computer to deploy a Kubernetes application to AWS. And that’s not the only modern thing you did with old computers…

Darko:  I have a weird hobby; I collect old computers. The reason I do this is because I skipped a big part of computing in the 1990s and 1980s, so I wish to experience that. You may ask yourself now, “But what do you DO with those old hunks of metal?”. I try to do two things: 1.) Restore them to their previous glory by cleaning and repairing them, and 2.) Make them do something they should not do – like connect to the internet.

Now I come to the article I’ve written. In short, what I did here is:

I used a Tandy 102 portable computer from 1986 and deployed a Kubernetes application to AWS.

The article goes into detail, but I “simply” used the Tandy 102 as a “dumb terminal” and ran kubectl commands from a more modern computer. Some would say that is cheating, and I would agree with them. The Tandy 102 was never meant to run something like a networking stack, let alone kubectl.

The idea came from thinking about something very modern (in a tech sense) that I can do with something very old. I have a few more things I’ve done but not written about it:

Training a Machine Learning model on a Pentium 2 Computer, deploying serverless applications with a DEC teletype, building and deploying cloud infrastructure with a Commodore 64, deploying a container cluster onto 3 Apple Macbooks from 2007.

Again, “Why Darko?”. Well, I find it fun. Fun to stretch the capabilities of technology and maybe give someone a nostalgic chuckle.

Technology has not changed that much in 40 years

What lessons did you learn from this project regarding old and new technology?

Darko:  One thing that stood out for me when doing a project such as this is that technology, in its essence, has not changed all that much over the last 30-40 years. Yes, we have moved on with bigger, better, faster systems, but the core concepts remain. The CPU still has cycles, the memory still has its addresses, and the input and output devices still (kind of) do the same thing. It shows that even old (very old) hardware can be used in a pinch to do more modern stuff thanks to the backward compatibility of modern systems. More specifically, thanks to command line tools and Linux.

Everything as a code

Please share some predictions on what you thing the future will be like in tech and how to future-proof your career?

Darko:  I will speak from a very biased position here, as I do work for a cloud vendor, but my opinion when it comes to the future of tech is the following:
1) Everything is on the cloud. Yes, unless there is an absolute need for a local data center (regulatory or latency requirements), all workloads should use the cloud. Reasons are plenty, but as an engineer, for me, the biggest reason is the ability to try new things, experiment, fail, and try again.

2) AI/ML is the wave of the future. If you are not using AI tools to help you do a better job, you better get started. With the availability of AI coding companions such as Amazon CodeWhisperer or GitHub Copilot, you will only benefit from those as a developer. Besides just using AI/ML tools, see how AI / ML can benefit your workload. Is there a need that AI can fill in your product? Will it improve the end-user experience?

But also, remember these wise words: “Never use AI unless you need it”.

I am trying to say that do not try to shoehorn AI into your application just because everyone else is doing it.

3) Everything as a code – since everything is in the cloud, everything should also be coded.

If you are not writing your infrastructure as code, you are doing it wrong. If you are not creating configuration elements as code, you are doing it wrong.

You are doing it wrong if you are not adding audits as code. Automate your job away by doing everything as code, and you will be able to reach any scale.

4) The best programming language is the one you are good at. So, pick a language that makes sense and get good at it. Just try not to make that language an esoteric one and stick with the mainstream. Do not worry too much about the latest and greatest and hottest languages, if you know one language well, others will come quickly.

The post Meet Darko, who built and deployed cloud infrastructure with a Commodore 64, a Kubernetes app to Tandy 102, and that’s not all. appeared first on ShiftMag.

Fortunately, there are tools and processes available to facilitate smoother interactions.

Understanding FinOps

You can call it Cloud Financial Management, Cloud Financial Engineering, Cloud Cost Management, Cloud Optimization, or Cloud Financial Optimization, but FinOps has emerged as the widely adopted industry term. The official definition comes from the FinOps Foundation Technical Advisory Council:

FinOps is an evolving cloud financial management discipline and cultural practice that enables organizations to get maximum business value by helping engineering, finance, technology, and business teams to collaborate on data-driven spending decisions.

FinOps Foundation Technical Advisory Council

Effective communication

Cloud costs can often be so unpredictable that it’s no wonder that they have become a running joke and inspiration for memes.

To address this challenge, Tajana Belina, a FinOps practitioner from Neos, a certified FinOps training partner and service provider (also a company behind CloudVane — a multi-cloud cost management and automation solution that consolidates cost and usage data), suggests leveraging the tools provided by the FinOps Foundation.

For example, the Foundation’s Social Aspects of FinOps Workgroup equips FinOps practitioners with tools to effectively communicate with executives, engineers, operations, finance, and procurement. The ultimate goal is to foster collaboration across these silos, ensuring the organization avoids unexpected, inflated invoices, says Tajana, Workgroup’s member.

The FinOps Foundation is working to facilitate adoption because all these separate silos must work together with one simple goal – to not end up with an invoice at the end of the month that the company isn’t sure how it got to or why it’s so big.

Tajana Belina, Neos

Being proactive

One of the critical approaches to preventing cost-related surprises is proactive management. Infracost, among the available tools, assists engineering teams in assessing how code changes impact cloud costs. By scanning Terraform code and analyzing over 3 million prices, Infracost generates simple, comprehensible cost estimates prior to launch. Notably, it offers detailed breakdowns of cost impacts on each resource affected by changes. Users can get helpful comments in real-time such as: “This change will increase your AWS bill by 25%”, says its cofounder Hassan Hosseini.

This open-source product addresses the complexity of cloud cost management, supporting individual contributors. Infracost Cloud, a paid product, also provides visibility for central platform teams and FinOps teams. It facilitates tracking cost changes, setting up guardrails, receiving notifications, and blocking pull requests exceeding predetermined budgets.

Users can also set up policies for best practices. It also supports Jira integration, which is important because the majority of changes to the infrastructure come from the product, so people working on it should also see how much anything costs.

Hassan Hosseini, Infracost

With over a decade of experience in cloud cost management, the tool’s founders aimed to address the issue of engineers not being aware of infrastructure costs. By making Infracost open-source, engineers can freely explore, test, and adopt it, as they often lack access to company credit cards.

When to consider FinOps?

The success of FinOps implementation hinges on making it easy for engineers. As the formula suggests, Cloud costs = usage x unit price. While finance teams influence unit prices, engineers play a critical role in impacting usage. Recognizing this, Infracost aims to integrate seamlessly into everyone’s workflow, encouraging collaborative data-driven decision-making across engineering and finance departments, Hosseini explains.

Whatever approach or tool you choose, one is certain – you shouldn’t wait for that first invoice that will shock you. According to Belina, you should implement FinOps immediately. Whether transitioning to the cloud or already operating within it, organizations should prioritize FinOps from the outset. By incorporating this approach early on, businesses can optimize their cloud spending and avoid potential financial pitfalls.

The post How to implement FinOps? Make it easy for the engineers! appeared first on ShiftMag.

Hardware is fun again, wrote DHH when he posted a photo of two pallets of R7625 Dell servers.

It’s been a long time since I last saw a physical piece of hardware used to run our services at 37signals. 

David Heinemeier Hansson, or DHH, the cofounder of project management tool Basecamp and emailing product Hey (and the founder of Ruby on Rails), has been detailing their “exit from the cloud” for some time now. He announced 37signals were leaving the cloud in October 2022 and has been chronicling the journey in detail since, advocating for medium-sized companies to stop bleeding server money:

Renting computers is (mostly) a bad deal for medium-sized companies like ours with stable growth. The savings promised in reduced complexity never materialized.  

David Heinemeier Hansson, 37signals

And the world paid attention. It seemed the time was high for CTOs or people responsible for infra costs to start voicing their frustration with their cloud bills.  

We’ve talked to three people in charge of infra at medium-sized global companies with a significant amount of load, and it turns out DHH may even be late to the party! 

Doing the math

At ReversingLabs, a software supply chain security company, on-prem data centers were their choice from the get-go. The main reason was cost, as they process a vast amount of data – even in 2011 when they started, it was a financially sound choice. Their VP of Technology Igor Lasic shares that they evaluate their strategy every two years, and the numbers are always in favor of self-hosting:   

Hosting everything on AWS would cost us approximately 10 to 15 times more than self-hosting – even when you include renting servers and salaries for engineers managing data centers into the calculation.      

Igor Lasic, ReversingLabs

37signal’s eye-watering cloud bill corroborates that. In 2022 they spent $3,201,564 on cloud services and almost a million on AWS! Since their project management application, Basecamp, is run almost entirely on their servers, this is just the bill for their emailing service, Hey, which was initially completely cloud-based.   

The savings from the migration come to about $1,5 million a year. And we’ll have much faster hardware, many more cores, incredibly cheaper NVMe storage, and room to expand at a very low cost, he adds. 

When SofaScore, a sports data company, did their math, the result was the same. Self-hosting just made more financial sense, says CTO Josip Stuhli:  

Not an easy decision, but we’ve reached a stage where we processed so much data that we paid more for the traffic than for the servers. Thad led us to move just one layer of servers that generated most of the traffic out of the cloud to control the cost. When making that analysis, we accounted for a way oversized setup, and the cost was several times lower than our cloud spend at the time.   

Josip Stuhli, SofaScore

The migration was smooth, with some minor iterations and optimizations. After a while, SofaScore moved the whole thing to Kubernetes to get some of the benefits of the cloud, like smart load balance and self-healing. SofaScore’s engineer even shared the technical details on their “descent to bare metal Kubernetes” at Shift Conference:

But what about operations and maintenance? SofaScore and 37signal have taken different approaches to handling this issue, but the cost-benefit ratio still favored self-hosting.  

In his post, DHH said they would not have to add people to their ten-people operations team, as their servers will be delivered to the Deft colocation facility, where the on-site facility team sets them up. The 37signals employees never physically touch the actual servers but can manage them remotely.  

SofaScore’s approach was more hands-on but is still not labor-intensive for the ops team:  

I will be honest, for the first four years of our transition, no team was in charge of infrastructure; it was just me. It was really challenging, and it took a lot of experimentation with various tools and solutions. The magic of the cloud is that it offers many excellent ready-to-use tools, and we had to find alternatives. We’ve eventually formed a DevOps team, and now they spend a small portion of their time managing the infrastructure.  

Cloud is still the future… For some

Hansson clearly states he wants to challenge the notion that “the cloud is the future” and that companies running their own data centers and owning, instead of renting, servers are somehow missing out or living in the past.

Any mid-sized SaaS business and above with stable workloads that do not benchmark their rental bill for servers in the cloud against buying their own boxes are committing financial malpractice at this point.

ReversingLabs Lasic tends to agree, noting that there has been a louder and louder resistance towards public cloud among engineers in the last couple of years:

It started when companies realized they never got to experience the benefits promised in the sales and marketing pitches. Even if you migrated all of your infra to the public cloud – which would cost you a lot, you’d still need in-house employees managing it.   

However, there is some fine print in those statements. As DHH says, renting computers is a bad deal for medium-sized companies with stable growth. Note the details: a medium-sized company with steady growth. Setting up in the cloud is still a great way to go for a small business just starting or companies with highly irregular loads who can’t predict whether they would need ten servers or a hundred.    

Stuhli notes that cloud also offers many fantastic tools that make setting up infrastructure straightforward and quick, and sometimes using those services makes sense:   

I would 100% recommend the cloud for any project just starting. Cloud also makes sense for companies with a monthly or yearly subscription business model because they can model their system for a predictable number of users. In that case, the infrastructure cost is neglectable compared to the revenue brought by the user.   

Setting up in the cloud is also a fantastic solution for companies that are just starting or are growing fast and need to scale quickly. At Infobip, a global omnichannel communication services provider, they prefer a hybrid multi-cloud strategy – out of their 40 international locations, some are smaller and set up in the public cloud, and some are bigger and have on-prem servers.   

Oliver Lovakovic, Infobip’s Infrastructure Engineering Director, says hosting in the cloud is an excellent choice when you have to set up quickly to test a market:     

It may cost more, but sometimes you don’t have the internal expertise or the time to build it. As the load starts growing at a location, it makes more sense to start building on-prem equipment and expertise. The increase in cloud cost is more or less linear, while on-prem investments balance out with scale.

Make it a matter of choice, not necessity

Whether you’re choosing cloud, self-hosting, or hybrid, it’s essential to keep your options open – circumstances, as well as business plans, can change. Having an experienced team prepared to switch between hosting setups is essential for risk mitigation, Lovakovic points out:  

You want to be in a situation where you choose the cloud because it suits your needs and makes sense for you in terms of cost or flexibility. Not because you don’t have in-house experts and are locked in with a cloud provider with no way out in the short or mid-term.   

Oliver Lovakovic, Infobip

Besides a lack of expertise in self-hosting, you should also be wary of “vendor lock-in,” warns Lasic from ReversingLabs. That could force you to make decisions not in your best interest:   

If we hosted all of our data on one public cloud and wanted to switch to another public cloud or start our own setup, the cost of that change and getting everything out would be so significant that we would be forced to stay whether we wanted or not.

Their real challenge, however, is not deciding on one or the other; it’s defining the current and future needs of your product, Stuhli concludes: 

Indeed there are companies like ours for which their own infrastructure makes more financial sense, even when you add the cost of engineers. Companies that would benefit the most from migrating to bare metal systems are those that generate and process a lot of data or offer a free app. Of course, there is no silver bullet when it comes to infra, and the real challenge is to know the product and the business model in-depth and then custom design the infrastructure to fit that particular product.  

To spice the debate up towards the end, let’s also throw in some cultural context in the mix. Considering the number of layoffs at tech companies and startups needing to cut costs in the downturn, there is merit in examining whether the cloud is the best option. If not, follow DHH’s advice and cut cloud costs before cutting payroll.

It may be more complicated than laying people off, but it’s worth it. 

The post DHH and 37signals are saving $7 million by leaving the cloud. Should you do the same?  appeared first on ShiftMag.