https://https://www.youtube.com/watch?v=oXkqwdDZsTc
This article supplements an episode of the This Dot Labs Podcast on Infrastructure with Rob Ocel, Tracy Lee, Jarrod Overson, Director at Shape Security, and James Snivey, Director of Engineering at Shutterstock.
Codebase infrastructure is not a one-size fits all topic. There are numerous factors that impact a developer or team’s choice to pursue a monolithic, or micro-service based system. For many approaching the question of what infrastructure will best support their databases and services, they are doing so through the lense of migrating their codebases, and either centralizing their systems, or breaking them up.
Shape Security Director Jarrod Overson reminds us that any infrastructure should be built with the knowledge that systems and technologies will change and disappear, often without notice. Though this constant seems more challenging to distributed systems, he adds that it is possible to build support into a microservice based infrastructure in order to mitigate some of these possible roadblocks, so the phenomenon of digital evolution is not necessarily an argument against distributed systems. That being said, poorly built micro-service infrastructures can lead to the presence of many disparate breaks and bugs when certain technologies change or are replaced. The benefit, therefore, of monolithic systems, is that you can reasonably rely on your code existing and being easily accessed at any point in time.
Microservice systems often times better allow developers to map functionalities, and sequester elements of relational code within a given codebase. They also offer certain advantages when it comes to conceptualizing complex business practices, and offering the capacity to scale. Some enterprises choose to break up their monolithic codebases in order to create a network of smaller microservices, but Overson warns teams to be careful. He argues that breaking up systems can be extremely difficult for those without any experience in doing so, with Rob Ocel adding that developers need to carefully map their biggest routes in order to ensure a logical microservice system organization.
When thinking about the use of NoSQL versus traditional relational databases, you should consider what types of data will be referenced to perform the functions necessary to operate the corresponding applications. For example, if a user accesses a simple interface, and that interface requires the system to call and piece relational data, it will struggle to do that as quickly and cheaply as a relational database would. These issues, of course, will only be exasperated by scale- another disadvantage of NoSQL.
Shutterstock Director of Engineering, James Spivey points out, however, that the use of NoSQL and relational databases are not mutually exclusive, and that certain infrastructures can better serve different areas of a system. He describes what NoSQL does as “flattening” data, which can sometimes better suit complex systems that don’t require frequent edits. He also adds that NoSQL has a ton of amazing resources, and is extremely well documented. But all agree that the choice to pursue a certain infrastructure needs to consciously reflect operational needs, and the types of data being stored within a system.
The group goes on to discuss IaaS (Infrastructure as a Service) technologies. These technologies, which include products from Microsoft, Google, and Netlify, afford developers the opportunity to spin-up and publish powerful systems quickly, and with relative ease. Spivey applauds these services for offering low risk platforms to create proof of concept systems that can inform a developer’s choice to pursue certain infrastructural types. He also adds that these services simultaneously strengthen communities around the topic of web based infrastructures, and open up conversations among developers, helping everyone’s understanding about this complex subject.
Whether building a new system from scratch, or pursuing a new infrastructural design, teams are encouraged to think about how their systems will process data, whether they want to implement a query language like GraphQL, and whether their teams have the support in place to successfully break-up or consolidate their services.
About the author
