This post mostly deals with situations where you have a medium to large (~ 1 million LoC) on premise legacy application that you think about moving to the cloud and maybe splitting into microservices. It is neither an advertisement for doing it nor a don't do it post. It's just about things you have to be aware of and that are sometimes easy to miss.
First off, it will probably be more difficult and take much longer than you'll ever expect - by a lot.
Hofstadter's Law
It always takes longer than you expect, even when you take into account Hofstadter's Law.
Douglas Hofstadter
If you're new to Services
There are still plenty of client applications out there that directly connect to the database. Cloud usually means services, although you can certainly do other brain-numbing things. So what do you need to consider.
You need to define an API.
Things to consider are:
- Who will use it? Do you expect developers from outside your company to use it?
- How do you ensure it stays consistent in naming and the way it's used?
- What 'flavor' you want (REST, GraphQL, GRPC, ...)
- How you'll want to handle backwards compatibility:
- Can you update all your customers to a recent version, say every 1 year or do your services need to serve older clients?
- What happens if a customer wants to stay on an older version?
- ...
- Making software backwards compatible can be a lot of work. It makes your code more complex and more prone to errors. It takes time off your "new feature"-budget. It might prevent you from refactoring and paying down technical debt.
- You'll likely need to log more.
Mircoservices
Microservices are all the rage. They allow you to scale your app, update only parts and therefore to iterate faster (and hopefully with less fear of side effects). But they're also not easy to implement correctly. For one, you can't half ass it. If you have more than one service you enter the world of microservices, no matter how large they are. You'll need or at least may want to think
- about containerization and orchestration
- about deployment (blue/green, non-destructive database updates, ...)
- about telemetry, service dashboards, alarms and gathering logs (you want to know your entire system is about to crash before the users call)
- about message buses
- about how the services interact with each other and how clients use them
- about eventual consistency
- where your bounded contexts are
- ... One important thing, microservices don't make your application faster per se (on the contrary), but they allow you to iterate faster. Fail fast, recover fast.
Know How
Depending on where you start, and where you want to end up. You need to learn a lot. This might affect multiple departments. Developers will need to learn how to use the new tools and get into a services mindset. You might need to setup an operations or SRE team. Your customer support needs to learn a new application - so will your customers.
Organizational and Cultural Changes
These are always some of the hardest and most underestimated things on the list. You'll need to adopt a new mindset to reap the benefits and this affects the entire organisation. Changing things that were done in a certain way is hard, even harder if you don't have buy-in.
- You want to iterate and release faster? Can your customer support handle the increased speed? Can your QA team? Can your documentation team? Your customers?
- Depending on whether your users work around the clock, you might need to think about SLAs and on-call service. On-call service can be expensive and disruptive/make people very unhappy.
Customer Support
What often happens with on-premise software is, that your Customer Support team (2nd level) starts "messing" around in the database. Developers or they themselves might write scripts to fix little things, because that's easier then to rollout a new update. An a complex, multi-tenant application you probably don't want that to happen anymore.
Security
Especially if you're making the step from an on premises app that is only accessible from within a company's network, to a "public" application, you're security needs will probably rise drastically.
- Consider recurring security reviews of your app.
- Figure out what your hosting provider provides you. Cloudflare DDOS protection, ...
Legal Stuff
Another huge part that can be annoying AF, is all the legal stuff you need to navigate.
- what kind of data do you store? Are there limitations on hosting, e.g. you're not allowed to host data outside of your country, or not even in your country if the company running it in your country is subject to the Cloud Act, ...
- do you need to be able to hand out or completely delete all data of one of your customers, customer's customers or employees? #rightToBeForgotten #gdpr
- do you need to physically separate data of different customers?
- do you need to create an audit trail, how detailed does it have to be?
- ...
The answers to these questions can influence your choice of hosting provider, architecture and tools.
Migration & Transition
Usually you can't just flip a switch and you're in the cloud. The transition is connected with actual costs and money you don't make because you're transitioning.
- The longer the transition takes, the more it will cost.
- Transitions mean you'll have to maintain two products, that might be technically wildly different.
- Your customer support will have to know to applications.
- You wont be able to pump out as much/any new features as you used to.
- You might need to implement features multiple times. There are always features that for legal or other reasons need to be implementation in your (now) legacy app as well.
- Depending on your code quality, porting logic can be very hard and time consuming. You might need to understand code someone who doesn't work here anymore, wrote ten years ago. There might be edge cases that are not clear, "it's not a bug, it's a feature" stuff. And, even if you understand what the code does, you might ask yourself "Why the f*** was it implemented this way?!". Lucky those with automated tests.
Discussions, Backtracking and Public Relations
The human factor is not to be underestimated.
- You'll need to discuss a lot of things and not everyone will agree.
- You'll probably need to discuss the same things multiple times. Write down your decisions and why you decided the way you did.
- You'll doubt that what you're doing is the right thing and paddle back.
- You might have to convince your customers. If you're taking your application into the cloud, you also take your customers' data into the cloud. They lose data sovereignty and they might not like that. Additionally you add another dependency (hosting) which is a loss of autonomy - some customers will be fine with this/even glad, others will hate it.
Money
- all this stuff will cost a lot. Make a budget, even if it's a very rudimentary Excel sheet where you can plug in numbers. I know it sounds silly to mention this, but you would be surprised how often this is not done.
- Stuff that belongs in your Excel sheet:
- One time stuff like initial knowledge building. Say you want to start with a core team that gets up to speed with Docker, 3 people at an hourly rate of $100 and you expect they need 40h, that's a cool $12'000 bucks. Then, they need to pass on that know how to 20 more people...
- Recurring stuff like hosting costs, licenses, ... I like to have monthly and annual numbers.
- Recurring stuff that scales with the number of people. There's always new stuff to learn about Docker, you might want to schedule a few hours a year per person to update that know-how.
- Stuff that will accompany you during the migration. Your customer support needing to learn to support two applications at the same time, the cost of not being able to implement and sell new features, ...
- play with these numbers, what does it cost to onboard a new team member? Plugin expected/realistic numbers, what happens if you double or triple them, ...?
- juxtapose those numbers with your expected benefits, try to quantify them. For example, installations/updates are easier in the cloud than on premise.
- Show your budget to everyone, let everyone play with it. You'll be surprised with what "creative" costs, that really matter, people come up with.
About Hosting
Figuring out hosting costs in advance can be hard. There are calculators with options upon options but in the end, you'll likely only really figure out the price tag when your customers use your app.
Final Words
In the end you need to know what you want and weigh the (expected) benefits against the (expected) effort.
Keep on struggling
Top comments (0)