Developing a Cloud App? Consider the Benefits of Microservices Architecture
TransNexus says the future of its enterprise-grade communications business lies in the cloud. Alec Fenichel shares with IDN five big lessons his team learned when using microservices to build cloud apps.
by Alec Fenichel, senior software architect, TransNexus
Tags: apps, architecture, AWS, cloud-native, data store, microservices, SaaS,
senior software architect
"Building microservices architecture to deliver cloud applications is vastly different from building on-prem infrastructure. Here are five lessons we learned."
The time was right. After 20 years of providing an on-premises solution, my company, TransNexus, decided to move our software to the cloud.
The scale and price point of the cloud would allow us to go after smaller telecom customers around the country who previously couldn’t afford to procure and maintain expensive data center infrastructure. Instead, they’d be able to license our cloud product for a single monthly fee, and we would guarantee availability, scalability, and security of our Software as a Service (SaaS) platform.
TransNexus provides services to telecom companies and large enterprises, including least call routing, toll fraud prevention, robocall prevention, denial of service attack prevention and call authentication, among others. Given the critical nature of these services, our software has to be reliable and secure, while meeting the low-latency demands required of the telecom industry.
We have a great on-prem product, and because of that, it was tempting to simply tweak existing code, upload it to AWS and call it a day. It likely would have worked and wouldn’t have been too disruptive to our development processes. However, our on-prem solution is meant to be run on-prem, not in the cloud. So, we opted to build a new SaaS platform from scratch so we could optimize for the cloud.
We were undergoing cloud transformation to create efficiencies and optimize the scalability, performance and availability of the cloud, and simply pushing existing code to AWS would prevent us from fully taking advantage of everything the cloud has to offer.
Why Microservices is an Appealing New Architecture
From the very beginning, microservices seemed like a good way to build our cloud platform. It would allow us to manage and scale each individual service separately from each other.
For example, let’s say that our least call routing service saw a spike in demand. We could easily scale up that particular service without having to overprovision other services. Or, what if we needed to issue a critical patch for our robocall prevention service? We could do that in a silo without impacting other services. Microservices delivered through the cloud would give us the agility to meet granular customer demands in real time in a cost-efficient and streamlined manner.
However, building microservices architecture to deliver cloud applications is vastly different from building on-prem infrastructure — from the way it is architected and deployed to how it is monitored and secured. Here are five lessons we learned when building a microservices architecture:
1. Identify an End Goal and Develop a Plan
There’s no doubt that we were taking a risk. We wanted to open up our product to a whole new market that exists in the cloud moving forward. From the very beginning, we set out to build a new platform from scratch that mirrored the functionality of our existing solution. Microservices made that easier. We could easily compartmentalize development around individual tasks, making it more manageable and scalable. Our goal was to make the best possible solution for our customers while streamlining backend management as much as possible.
2. Design for Failure
We assumed that everything was going to fail and put safeguards in place to ensure that all tasks were completed. For example, we have a database that maintains a task queue that assigns jobs to cloud servers. When a task comes up, a server takes and executes it, locking out other available servers. However, if the task fails, we built in a mechanism that would add the job back to the queue so another server could pick up the slack. This ensures that failures out of our control (such as an AWS data center going down) don’t impact overall performance.
3. Make the Right Build vs Buy Decisions
Building microservices architecture from scratch can be daunting — especially if you’ve never done it before. We made sure to recognize our limitations and leverage the expertise of people who had done this before. We had to make a list of components we could build ourselves, and a list of components that we’d be better off buying. When it came down to it, we ended up partnering with infrastructure vendors like Redis Labs and Amazon Web Services, who had built a microservices architecture before, and focused our internal resources on building out the features and functionality of our own solution.
For example, Redis Labs already had an out-of-the-box, in-line database that would allow us to share data in real time. There was no reason to reinvent the wheel, and anything we built in-house wouldn’t have been as robust as what the vendor already had. Instead of focusing resources on building backend infrastructure from scratch, we focused our resources on what makes us unique — our app.
4. Use the Right Tool for the Job
There are hundreds of vendors out there, each backed by a powerful marketing operation aimed at convincing you that their solution is mission critical. Do your research. Talk to current customers. Understand exactly how each component fits into your planned architecture. Take the time to read message boards and determine how the vendor interacts with customers — whether they are responsive and take concerns seriously, or if their customer experience is less than stellar.
Sometimes, however, there’s not a clear-cut answer. In fact, in one instance we ended up using several database platforms because each responded better to different use cases.
5. Build Around a Central Data Store
Every project is different, but if there’s one piece of advice I’d like to convey, it’s this: build your SaaS platform around a central data store. When building a microservices architecture, data consistency and resiliency is critical. You have thousands of services that need real-time access to up-to-date data to make quick decisions in real time. Synchronizing disparate data stores spread out across the cloud is complex, and, frankly, hasn’t been mastered yet. Having a single source of truth that microservices can dip into ensures that you are making informed decisions based on the latest information.
The decision to build our SaaS platform from scratch on microservices architecture was risky, but it paid off in spades. Now, we’re able to deliver telecom services to more customers through the cloud in a more efficient and effective manner. Microservices make our SaaS platform more scalable, reliable and powerful, giving our customers the real-time services they need to manage and protect their telecom networks.
Alec Fenichel is a senior software architect for TransNexus, a software development company that specializes in applications for managing wholesale VoIP networks.
Related:
- InfluxData's Latest Updates Optimize Time Series Data for Better Performance, Scale and Management
- Actian Zen 16.0 Update Simplifies Delivery and Boosts Performance of Edge, IoT Apps
- Virtana Infrastructure Performance Management Adds AI-driven Capacity Planning
- e2open’s Supply Chain SaaS Updates Help Firms Reduce Operational Risks with Deeper Visibility
- Report: Endor Labs Identifies 2023 Operational, Security Risks To Open Source
All rights reserved © 2024 Enterprise Integration News, Inc.