How Rebrandly Views the Current and Future Role of Microservices
In the future, companies will offer Microservices as a Service so apps can run continuously. Learn what this means in this interview with the CTO of Rebrandly.
Join the DZone community and get the full member experience.Join For Free
How is your company involved in the creation or use of microservices?
We leverage a microservice architecture to support our API with asynchronous tasks and to divide the backend into different realms, which reflect our company and product structure.
What do you see as the most important elements of microservices?
The ability to keep things as generic as possible: every microservice should do only one thing, no matter the message source context, no matter what is next. Splitting big tasks like that is much more maintainable and programming business logic is a lot easier.
Which programming languages, frameworks, and tools do you, or your company use, to build out microservices?
Most or our microservices infrastructure has been done with NodeJS with Express router: you can avoid type definition, which helps a lot when you are decoupling things. We “hate” XML and our brain is “JSON-shaped”: NodeJS is great at handling JSON messages and asynchronous actions too. We use Jenkins. It enables us to clone existing Jenkins jobs. We put the job in the machine using pm2 and it takes 20 seconds to deploy. That’s music to any developer’s ears.
How have microservices changed application development?
Every new microservice is a new flow: a new repository, a new set of permissions, a new machine or a new decision about where such microservice should live. The number of policies you desire for your services is the pain point: no code shared among microservices and you are soon applying the same new policy about logging, error handling, edge case management to all the microservices you have. Anyway, we started with microservices in production from day zero, and to date, we are happy enough in the development.
What kind of security techniques and tools do you find most effective for securing microservices?
Well, most of our microservices support our internal API, so they are just not visible and not reachable by external agents. If you break our API, you have HTTP-only access to our microservices: limit what can be done in HTTP, open only HTTP access from your Cloud itself and it is enough for our needs. A rule of thumb we applied to many microservices: no access to the database. Just process JSON and reach other microservices or the API itself again.
What are some real-world problems you, or your clients, are solving with microservices?
Batch operations in a REST API: we wanted every API endpoint to stay within a maximum latency and we realized a microservice to handle batch operation in asynchronous, rate-limited, fashion. It is our micro-jewel, it takes job definitions and performs HTTP API calls and other callbacks. Anti-spam tools: a super scalable API should not access external APIs’ HTTP endpoints at high rates (let the microservice do the dirty job, let it risk a bottleneck). Also, we use them for internal stats, mailing, URL metadata fetching and many more.
What are the most common issues you see affecting the implementation of microservices?
We don’t trust synchronous HTTP operations among services and we use queues everywhere so that we can stop and start a microservice whenever we need to. To get an easier development, you have to face initial configuration and driver setup costs to connect your service to different protocols. Queues come with a cost. I see some companies are implementing a Configuration microservice with the only purpose of sharing configuration strings across microservices: this is a good example of which kind of extra-effort you find when you move to microservices, as your configuration needs to be properly distributed too.
Do you have any concerns regarding the current state of microservices?
Every night I ask myself if all microservices are doing their job as expected. I see that the proliferation of microservices up and there can be perceived as a loss of control over things.
What’s the future for microservices from your point of view - where do the greatest opportunities lie?
I see a future for microservice sharing: many good GitHub projects have no real support for run-forever or run-on-event patterns like a microservice should have. When people deliver their own tools, they could also provide an HTTP API to use it on production and to speed up its microserverization. I look forward to companies offering Microservices as a Service so my apps can run continuously.
What do developers need to keep in mind when working on microservices?
You shall use standard or self-explanatory names for message properties. You shall use known libraries. You shall do one thing and do it well. And, please, check for null values. Jump in using JSON and keep looking for opportunities to use.
Is there anything you’d like to know about what software developers are doing with regards to microservices?
Yes: I’m asking myself if someone is proposing some Standard in this jungle of homemade microservices. I like some jazz on procedures, but when you work on professional tools and you frequently hire people, Standards help a lot.
What have I failed to ask you that you think we need to consider with regards to microservices?
Probably a question about the cloud and machinery costs of maintaining microservice infrastructures. Try to create a chain of microservices and to apply whatever autoscaling strategy to it: you can lose control on your architecture size, and then on your costs.
Opinions expressed by DZone contributors are their own.