I remember when our servers sat in the room next door. We could touch them, and everything around them was our job. Then, little by little, the cloud came in. We moved our servers into it. Then more and more services started to appear around it, backups, monitoring, security, and today almost everything we need is a click away. For me, the question of a server next door or the cloud doesn’t even come up. The question is how well you’ve set up your infrastructure in it.
My work involves a lot of different things every day. One of the ones I enjoy most is building software systems. When I sit down with their cloud infrastructure, I get a real sense of satisfaction, and it keeps me improving it all the time. A small improvement today, another tomorrow, a third next week. If the foundation is designed right, these small improvements don’t stay separate patches. They build on each other like a lattice, and over time they become a solid structure that a whole product can stand on.
Right now we’re preparing the platform BoroBit runs on for a technical review by AWS. It’s a natural step for us, because soon we’ll be offering part of BoroBit through AWS as well. Before handing it over for review, I sat down and reviewed it myself, against the same six pillars and with the same questions AWS uses to check systems. It isn’t the first system I’ve reviewed this way, but it’s ours, so I can write about it openly. And everything here applies to any cloud infrastructure.
If I had to put it in one sentence: good cloud infrastructure is designed from day one for the years ahead, with all six pillars of good architecture thought through.
Where it hurts
Few business owners think about their systems in terms of pillars. They think about what worries them.
Every new release is stressful. Updates break something that used to work. Everything depends on one person. Then come GDPR and NIS2, the fear of a breach, and the question of who has access to what. If something goes down, nobody is sure there’s a backup, or whether anything can actually be restored from it. On the busiest day, the system slows down. The cloud bill grows every month. And the largest companies now have to report their environmental footprint too – smaller ones don’t, but their big customers may ask.
The industry sorted these worries out long ago. AWS groups them into six pillars in its Well-Architected Framework. Google has the same six, Microsoft five of them. Each of the pains above falls under one of the pillars, whatever the system does and whichever provider it runs on. The pillars even apply to the server in the office. Not one of the questions asks where the machine is.
In Bulgaria, the cloud is still more the exception than the rule. According to Eurostat, in 2025 17.8% of companies with ten or more employees used paid cloud services, against an EU average of 52.7%. That puts Bulgaria last in the European Union. It means that for most companies, the most important decisions are still ahead. And they can be made right from the very start.
Let me go through the pillars one by one. What each one means in plain language, how we do it in our system, and what to ask about yours.
A new release is a non-event
Operational Excellence
This is about the everyday work with the system. How you ship changes, how you find out something is wrong, and what you do then.
I remember when releasing a new version was done by hand. One of the systems we’ve looked after for years has more than twenty microservices working together. Imagine preparing, releasing and checking each one by hand, then the next, twenty times over. The first thing we automated there was exactly that, releasing new versions. Our productivity went up several times over, and we took a huge amount of manual work off the team.
Today a new release takes us two clicks. Most recently we added an improvement to cash flows in BoroBit and had it with users within a few minutes. And not blindly, because the system itself checks that it’s exactly the right version and that it lands exactly where it should. The build is the same one that has already run in the test environment. It isn’t put together again, so what reaches users is exactly what we tested. The previous version stays active, and if something isn’t right, we go back to it. All of this is described in code and doesn’t depend on one person’s memory. And the time this frees up goes into the product, not the servers. We’re trying to do more and more with few people, with automation and AI, and the cloud is part of that path.
But automation rests on the right design. If it isn’t clear what you’re releasing and where, you’ll just repeat the same mistake faster. The cloud doesn’t make you fast. A well-organised cloud makes you fast. And by fast I mean how soon something new reaches the people waiting for it.
How much stress does a single release cost you? If something goes wrong, how long does it take you to go back? And if the person who usually does the release isn’t there tomorrow, can someone else do it?
You know who gets in, and how far
Security
Being in the cloud doesn’t make a system secure.
The cloud gives you security on two floors. The provider protects the cloud itself, the buildings, the machines, the network. You protect what you put into it, the access, the settings, the data. If your floor is designed properly, the provider carries much of the weight. If you use ready-made managed services, it also looks after the machines underneath them and their updates. But no provider can protect you from a door you left open yourself.
A small company can’t afford guarded data centres, encryption and copies in different places. For banks and financial institutions, regulation comes on top of that. For a team like ours, the choice is easy. We go deep into what we’re good at, our own system. For the cloud, we rely on the expertise of engineers who have been building it for twenty years. You can’t do both at the same level. Some companies set out to do everything themselves, and after a while it becomes clear it doesn’t work. There’s no need to reinvent the wheel. Use it.
Our test and production environments are in separate accounts, and infrastructure management sits in a third. An automatic check stops any infrastructure change that’s aimed at the wrong account. The platform is designed so that a regulated partner can get its own separate environment, and code it doesn’t need never makes it into its version at all. What isn’t there can’t be breached. Data is encrypted where it’s stored. And if your company falls under NIS2, the responsibility for this now also rests personally with management.
Who has access to your system and your data? Would you notice if someone had left but their access hadn’t? If a customer or a regulator asked tomorrow to see what you do about security, would you have something to show them?
If something goes down, you know how to get back
Reliability
This is the question nobody likes to ask themselves. If something goes down, what happens, and how long does it take you to get back?
In Bulgaria, almost half of companies don’t keep a copy of their data in a separate place. 54.6% do, against an EU average of 79.2% (Eurostat, 2024). But even “we have a backup” is only the start of the answer. What matters is when someone last restored something from it, and how long it took.
There are two decisions here that the business has to make. How long you can afford to be down. And how much of your most recent data you can afford to lose. IT people call them RTO and RPO. For one system the answer is days, for another minutes, and it decides what needs to be built and how much it will cost.
Our database has daily and weekly backups that we keep for weeks back, and we’ve checked that we can really restore from them. In July we rebuilt the whole environment from code when we moved it into our new structure with separate accounts. The parts of the platform are separated and work asynchronously. If a bank’s system stops responding for a while, the rest of the platform keeps working normally. If the same request arrives twice, for example after a dropped connection, the operation is recorded only once. With money, there’s no room for duplicate entries. And if any part of the system stops working, it restarts automatically, without anyone having to step in.
When did you last actually restore from a backup, not in theory? Will you know something isn’t working before a customer calls you? If you lost your whole environment tomorrow, how long would it take to bring it back?
It holds up on the busiest day
Performance Efficiency
The question here is whether the system holds up when everyone comes in at once. At the end of the month, or on the day of a campaign.
We were in one of the teams behind a system for a major sporting event. Picture more than a hundred thousand people in one stadium. In the cloud, capacity goes up many times over for a few hours, then goes back down after the event, and you pay only for what you used. Now picture it without the cloud. You buy servers for one day a year and then wonder what to do with them.
But the cloud only scales what was designed to scale. If everything is waiting on one overloaded database or one slow external service, more machines won’t help. It’s best to find the bottleneck before the big day, not during it.
The other big advantage is that almost anything that already exists in the world as a service, you can use in the cloud today. That’s why, wherever we can, we use ready-made managed services instead of running our own. Our database is with a specialist provider, our applications run without servers for us to look after, and our websites are served from the point in the network closest to the person.
Do you know what will slow your system down first if the load doubles? Has it been tested, or will you find out on the day it happens?
You know what you’re paying for
Cost Optimization
The cloud bill keeps growing – that’s one of the biggest pains and fears when we talk about cloud infrastructure. I’m not saying the cloud is cheap. I’m saying the alternatives aren’t cheaper. Designed properly, the cloud costs no more than they do, and for the value it gives, it’s the best solution. Again, designed properly.
The server in the office isn’t free either. It was bought, and then it ages, both the machine and its software. Someone has to update it, monitor it and replace parts, and that time costs money too. In the cloud, hardware isn’t your concern, and a new machine is up in minutes.
In the cloud, you pay for what you’ve switched on. If it’s set up properly, that’s exactly what you use. If it isn’t, you also pay for what’s been forgotten. In a survey by Flexera, companies themselves estimate that around 29% of their cloud spend goes to waste. That’s why the bill is mostly a matter of the right design and the right use of resources in the cloud.
A small example. Our website used to be on a rented virtual server, which is essentially still the cloud. Today inabit.eu runs on S3, CloudFront and CodeBuild, and it costs us pennies a month. The same logic applies to the platform. One shared environment serves many customers, and we build a separate one only where it’s really needed. For us, the one who designs the system and the one who pays for it are the same, and that helps a lot.
There’s a saying I often use. I’m not rich enough to buy twice. If you go for cheap, you won’t get far, because cheap ends up very expensive.
Do you know exactly what you’re paying for every month? Not the total, but what for. Is there someone who can explain why the bill has changed? And are you paying for something nobody uses?
You don’t keep more than you need
Sustainability
The sixth pillar is the newest. It’s about the hardware and the electricity your system uses. Large companies already put it in their reports, but the question is valid for everyone.
The server in the cupboard runs day and night, even when nobody is using it. In the cloud, one machine serves many people, and resources are started and stopped as needed. What’s good for cutting costs is usually good for electricity too. You switch off what isn’t working. You don’t keep data you don’t need. You don’t keep environments nobody remembers the reason for.
We don’t have a single server of our own. We use managed services. Most customers work in one shared environment, and we set up a separate one only for the large ones that really need it.
How much of what you pay for and maintain do you actually use? Are there environments still running and data still being kept that nobody uses any more?
What I learned
Every day at work you make decisions, and some of them won’t be right. What matters is that the main direction is right and the everyday decisions follow it.
My first mistake came right at the start. Five years ago we put BoroBit’s production environment in the US. Not that it’s a problem. It just forced us to maintain additional data protection agreements we wouldn’t otherwise have needed, because our users are here, in Europe. If I were starting now, I’d first decide where the data should live, and then everything else. Moving it later is much harder.
The cloud is a second life for software. It’s maintained in code, and it evolves and improves every day, just like the product on top of it. These aren’t just some servers that run and that’s it. They’re the foundation of the product, but they’re a separate, parallel universe of their own. That’s why the time you put in at the start into the architecture of the system and the cloud beneath it pays back many times over the years. When we started BoroBit, I was aware of this, and I took the time to build the system so it could evolve for years. Even then we chose ready-made managed services over our own servers. Today that lets us delegate. The cloud provider looks after the machines, their updates, the network and the hardware, and we look after the product. A well-organised cloud grows, takes peaks and recovers.
One more thing. You often do things right but don’t write them down. We also maintain software for financial institutions, not just our own. When DORA came, it turned out we already had most of the processes. We just had to describe them. The review of our platform showed me the same thing. We do a lot of things right, but they live in our heads. It also showed me a few things we’re going to do better.
In Bulgaria, only 13.7% of companies have documented ICT security measures, against an EU average of 35.5% (Eurostat, 2024). I think many of the others still do something to protect their systems and data. It’s just that nobody has written it down as rules. And that’s no small detail. What isn’t written down, you can’t hand over to someone else, and you can’t show it when a partner or a regulator asks for it.
How to check without being technical
You don’t need to be technical to understand what state your system is in. The questions I’ve marked under each pillar are the start. The next step is a conversation with the person who looks after your system.
Don’t ask them whether everything is fine. The answer will almost always be yes. Ask them to show you three things. The last restore from a backup, and how long it took. The list of people and systems that have access. And how a new version is released, step by step. Anyone who has done their job will show you right away.
If your system is on AWS, there’s also a free tool for this, the Well-Architected Tool. It goes through the same six pillars, and Microsoft has a similar review for Azure. The AWS tool has 57 questions. Ask them, too, whether they’ve run your system through it. If they haven’t, I’d recommend they do.
Trust
If yours isn’t a software company, and your system is in the cloud or soon will be, the cloud is something you don’t know up close. You know it’s fairly complex, and you know you need someone you can trust. In the end, it all comes down to trust.
Whether your IT person or agency is doing it right, you know best. For me, people matter most. How long have you been working with them? What does your gut tell you? It’s almost never wrong. Look, too, at how many projects they’ve worked on, how long they stay with their clients and what others say about them. Contracts matter, but they’re not the only thing that would make me let someone into my system.
When someone rushes their work or cuts corners, it makes me angry. But in infrastructure it’s especially insidious, because for a long time it doesn’t show. The system runs and everyone is happy. It shows on the day something goes down, when a peak comes, or when someone asks to see what you do about security.
We try to build our partnerships on trust. With one partner in the US, for example, we’ve been working together for twelve years. In that time we’ve looked after three or four systems together. The latest is six years old, and we’re still developing it. We look after it like a baby. When you look after a system for years, you live with the consequences of your own decisions. That’s how you learn what good infrastructure means.
For me, good infrastructure is the kind you can build on for years.
Petyo Stoyanov
Inabit