October 10, 2019
After decades of consistent investment in perimeter cybersecurity tools, cloud-based architectures have pushed IT leaders to reevaluate their strategies. There is still a place for perimeter defenses like firewalls, intrusion detection systems, and intrusion prevention systems. But adapting to cloud environments and mobility means creating a defense-in-depth strategy that goes beyond the network perimeter.
However, there’s no one-size-fits-all approach to defense-in-depth cybersecurity. What worked in the earliest days of public cloud adoption won’t exactly fit with the latest trend in cloud-native architecture—microservices today.
As important as it may be to embrace cloud-native architecture to support digital business initiatives, you should not dive in without taking these steps to solve security and visibility challenges.
Traditionally, applications have been built with a monolithic approach. Teams spend months or years building up a single project and then continuously tack on new features and capabilities as business demands call for them. The result is often a chaotic, interdependent architecture that’s increasingly difficult to scale.
In recent years, adoption of DevOps and ongoing efforts to increase IT agility have made replacing monoliths more urgent. For a while, it seemed like migrating workloads to public and private cloud deployments was the key to balancing traditional monoliths with agility needs. But increasingly demanding business use cases require more. And that’s why microservices have become such a popular IT architecture trend.
“The microservice architectural style is an approach to developing a single application as a suite of small services, each running its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.”
—Martin Fowler, Chief Scientist at ThoughtWorks and software development expert.
By breaking monolithic software into smaller microservices that run independently, you can continuously address business demands thanks to applications that are more flexible and modular. This is especially useful for hybrid cloud strategies.
Cloud-native microservices eliminate single points of failure in an IT architecture, making applications highly available and easier to maintain. And within a hybrid cloud strategy, you can further lower risk and increase cost efficiency by blending the flexibility of public cloud with the security and control of private cloud.
Ultimately, the right hybrid cloud deployment of microservices unlocks IT benefits like:
Agility: Application independence means your IT team can focus on innovation rather than maintaining sensitive and complex interdependencies in a monolithic architecture.
Scalability: The cloud-native architecture makes it easy to spin workloads up or down to utilize resources most efficiently.
Performance: Take advantage of large computing resources without having to worry about on-premises server deployments.
It’s impossible to ignore the benefits that microservices offer. However, without addressing the security and monitoring challenges that come with the cloud-native architecture, you risk opening the door for attackers to compromise your network.
With greater focus on microservices architecture, you’re simultaneously increasing your attack surface while degrading visibility by decentralizing workloads. Your security and monitoring strategy has to evolve and become more dynamic—and that all starts with maintaining visibility as the edge of your network spreads.
Before going too far with microservices architecture, you need to know how your network visibility fabric will work with hybrid cloud environments.
Looking to add visibility to your cloud deployment, but not sure where to start? Join us for a brief network Design-IT consultation or demo. No obligation - it’s what we love to do!
If the inline security tool goes off-line, the TAP will bypass the tool and automatically keep the link flowing. The Bypass TAP does this by sending heartbeat packets to the inline security tool. As long as the inline security tool is on-line, the heartbeat packets will be returned to the TAP, and the link traffic will continue to flow through the inline security tool.
If the heartbeat packets are not returned to the TAP (indicating that the inline security tool has gone off-line), the TAP will automatically 'bypass' the inline security tool and keep the link traffic flowing. The TAP also removes the heartbeat packets before sending the network traffic back onto the critical link.
While the TAP is in bypass mode, it continues to send heartbeat packets out to the inline security tool so that once the tool is back on-line, it will begin returning the heartbeat packets back to the TAP indicating that the tool is ready to go back to work. The TAP will then direct the network traffic back through the inline security tool along with the heartbeat packets placing the tool back inline.
Some of you may have noticed a flaw in the logic behind this solution! You say, “What if the TAP should fail because it is also in-line? Then the link will also fail!” The TAP would now be considered a point of failure. That is a good catch – but in our blog on Bypass vs. Failsafe, I explained that if a TAP were to fail or lose power, it must provide failsafe protection to the link it is attached to. So our network TAP will go into Failsafe mode keeping the link flowing.
Single point of failure: a risk to an IT network if one part of the system brings down a larger part of the entire system.
Heartbeat packet: a soft detection technology that monitors the health of inline appliances. Read the heartbeat packet blog here.
Critical link: the connection between two or more network devices or appliances that if the connection fails then the network is disrupted.