Technology is constantly transitioning, and in this state of continuous ‘in-between’, hybrid is king.
From manual to automated, physical to virtual, on-prem to the cloud, and now monolith to microservices and serverless.
Serverless today is a fresh and blooming ecosystem, yet when it comes to making the transition to serverless (or microservices) the future promises many aspects of growth and progress, but also a substantial amount of uncertainty. Will everything become pure serverless with zero orchestration, in just a few years time? Will we see a combination of serverless with microservices, and even with the classic monolithic apps? When contemplating these questions - One thing is certain: hybrid systems are a key aspect of technology and they are here to stay. Which is why we better pay them some attention.
Change is imminent. There’s tension in the air, and from the cutting-edge perspective, just like in the classic western, we have the good, the bad, and the ugly.
Each of these players come with its advantages and disadvantages, and each of them currently has a position on the field.
Considering a move to new technology, like serverless or microservices, may create strong tensions within a company. The resistance to the new may express itself on several levels:
It’s very tempting to fall into the utopian vision of a pure world. To think that it’s possible, for instance, to only run your project in serverless, or only in microservices. This mindset might work for the short-term, but it ignores the existing reality and its complexities. The tensions and frictions mentioned earlier will meet you in the next round and quickly pile up into technical and cultural debt. “Suddenly” You’ll find yourself juggling both the maintenance of the old systems and the integration of the new elements that are still being baked in.
There are many parameters that can affect the long-term success of your new project in this hybrid world. The following is a list of common key examples:
Language: This is one of the first things we need to choose when starting a new project. Will it be Go or Python? Would we rather use the language we’ve previously used, or should we choose one that seems to be the best match for the environment? The latter option is often considered to be best practice. In reality, however, it leaves the rest of the environment behind and ignores all other elements and frameworks, the handling of web requests, connecting the file system, etc.
Framework: The problem with existing solutions is that they are different for each environment. Each framework is often completely new and we will need to figure out how to adopt and implement it in practice. For example, if you worked with Flask or Django in Python in your monolith or microservice, moving to serverless you’ll have to go with something like Zappa on top of Flask, or Chalice.
Building and deploying: In serverless, we don’t need to pass through the complexities of the CI/CD pipeline since we can simply upload the Zip to Lambda. However, we should consider where this leaves us in relation to the existing code deployment flows- as we run a risk of losing our controls and policies for deployments.
Design patterns: With monoliths, developers are often used to working with monolith design patterns, for example, “Shared Process Memory”. It’s very convenient since all the work is in the same process, accessing the same memory. This changes with the move to serverless: everything is on the network and you have to use solutions like SQS or Kafka to synchronize your code components.
Monitoring: While there are classic monitoring products, such as Datadog, serverless offers up a whole new world with tools like Epsagon, IOpipe, Honeycomb, etc. This plethora of new solutions brings the challenge of picking the right offering for your needs, and more importantly, balancing the offering with the existing tools.
Debugging: the classic monolith allows you to attach a debugger and simply pause and observe. This isn't an option in serverless since there is no server to run and nothing to attach to. You can try SAM Local, and ironically enough, set up a server for debugging serverless.
So, how can we overcome these challenges? How can we, as devs, devops and SREs create the best configurations for hybrid systems and build the most efficient solutions to face these inherent challenges?
Embrace the hybrid future. Accept the fact that sometime in the not-so-distant future, your project will be a part of a hybrid environment and consider how you can develop it now, so when the time comes, it integrates and grows better.
Explore and innovate. Yes, there’s a variety of options and tools out there, but we still don’t have all the answers. Organizations and devs need to allocate time to experiment and gradually outline the best practices. The more we deal with these questions, the sooner we’ll find answers as a community. By allocating a small amount of time now, you’ll be saving your future self bucket loads of time and pain.
Use these 3 key concepts to create and measure up good hybrid solutions:
As part of an industry, we need to consider standardization and how we provide developers with a unified way to work with different elements. New vendor solutions should uphold 3 key parameters:
Create symbiosis: Instead of building a closed system, consider forming a symbiosis between the various parts of the solution. If you’re writing a function in serverless, ask yourself: Will the existing microservices benefit from it when you’re done? Would it be easier for them to work?
Leave room to mutate and evolve: When things only work separately and cannot connect to other elements, they eventually get stuck and stop generating value. But if you allow room for flexibility, a place to insert or change the code and connect to other platforms, everybody wins.
Provide transparency and observability: A solution with code that cannot be observed and understood is bound to eventually fail and lose its users and maintainers. Aspiring for your solution to be accessible and understandable by others is key to wider adoption and for allowing it to stand the test of time.
Support Interchangeability: As mentioned earlier, a good solution should be interchangeable with others.
Make it feel seamless: Developers who work with the solution should feel it integrates seamlessly with other solutions used by their company. No special effort should be made on their part to learn how to use your solution.
These are values we set into Rookout’s foundation from day one. Aspiring to be as complementary as we can to our ecosystem, our goal is to connect to as many platforms and solutions as possible. We want to create a better world, where developers can work with the various tools in a smooth and seamless way. And as you can see in the demo below, with Rookout it doesn’t matter which cloud you are using, or if you’re using Rookout on a monolith, microservice, or serverless function. It all works the same: by simply clicking a button.