Platforms Versus Stacks: What’s the Difference?
The difference between a platform and a stack is an important one especially when it comes to developer lock-in and having the freedom to assemble your own architecture and use data exactly as you want to, without barriers. Here, we’ll compare and contrast these two ways of thinking about data architectures.
What’s a platform?
Gartner defines a platform as “a product that serves or enables other products or services.” In the application world, platforms enable developers to build software without needing to concern themselves with underlying infrastructure.
Application platform providers purport to give developers everything they need to build their apps with a set of features that cater to their needs; they claim that you don’t have to care about any of the technologies that underpin it.
But what providers hail as benefits can also be problematic because a platform approach robs developers of choice. A platform isn’t necessarily assembled with a set of best-of-breed technologies, and it certainly isn’t made up of components that can be flexibly mixed and matched with other technologies outside of the platform.
For example, some app development platforms offer a great experience that enables developers to build apps quickly and easily. However, the tradeoff is that the applications that developers build on them are tightly coupled to the platform, making it all but impossible to move away from the platform.
For some developers, the simplicity and speed is a fair trade for giving up choice. But lock-in—to a particular set of technologies and a particular vendor—creates a whole host of problems. One of those problems is the inability to retain tech talent. Developers want to work with the best tools available for the job at hand. And those that don’t have the flexibility to develop with their preferred technologies are more likely to leave to work elsewhere.
What’s a stack?
A stack is a set of technologies that together form an architecture that solves a specific type of problem. Each of the technologies in the stack has a specific role and generally solves one particular set of concerns that the other technologies in the stack can rely on.
These technologies are often a mixture of development frameworks, libraries, middleware, and even infrastructure. Famous application development stacks from history include LAMP (Linux, Apache HTTP Server, MySQL, and PHP) and others that don’t have such a convenient acronym, like Tomcat/Spring/Hibernate in the enterprise Java development world.
A general characteristic of a stack is that each component has a well-defined boundary that determines its role in the stack. These boundaries are determined by a combination of product features and architectural decisions that simplify the overall solution and streamline application architecture decisions.
When selecting technologies for a stack, it’s important to understand those boundaries. Sometimes, technologies claim to do a lot, but upon closer examination they do one thing really well and fall short in other key areas.
For example, databases that execute queries very efficiently may also offer ways to execute application logic but fail to provide the testing and deployment capabilities needed by software developers. Or caching technologies might offer a few basic event-streaming capabilities but not at the level that’s needed to satisfy the requirements of a typical enterprise (e.g. Apache Pulsar). Depending on the problem your stack aims to solve, you might decide to draw boundaries that include or exclude these capabilities.
In other words, understanding the core capabilities that your stack needs to provide, and then selecting best-of-breed technologies to provide those capabilities, is crucial to building an effective stack.
Best-of-breed components will do more than just provide a few features—they offer the scalable, rich, and tested robustness of a standalone product that’s purpose-built for the task at hand.
What’s an open data stack?
We’ve discussed what a stack is and provided some examples of application stacks, but what is the data stack that we’re building and what problem does it solve? The phrase “open data stack” defines three fundamental aspects of what DataStax provides. “Open” of course refers to open source and our core philosophy that all parties benefit from software being developed in the open, with contributions from a broad community of stakeholders.
Our open stack is focused on satisfying the data requirements for real-time applications that operate using a cloud-native architecture: Stargate, Apache Pulsar, and Apache CassandraⓇ, all running on Kubernetes.
Each of these components has a defined boundary that encapsulates the set of concerns that it is responsible for addressing. Stargate provides the modern interfaces (APIs) for developers who are building real-time applications to access and work with both persistent data as well as streaming data.
Cassandra provides the infinitely scalable, highly performant NoSQL engine for data at rest. Pulsar provides the infinitely scalable, highly performant streaming engine for data in motion. And underpinning it all is the elastically scalable, cloud native container orchestration capabilities of Kubernetes.
Open means no limits
The key difference between a platform and a stack is choice. Abstracting away the technologies that operate below a platform in order to ease development also takes away a lot of your freedom to use data as you see fit, without barriers to entry, exit, or integration.
Essentially, a platform experience is great on day zero and day one, but on day two, it quickly becomes apparent that you’ve entered a walled garden–one that might seem like a comfortable place at first but can soon become confining.
In contrast, an open stack is assembled with products that are best-of-breed technologies with the robustness of standalone products that are integrated but also integratable, preserving users’ freedom of choice.
Learn more about how you can put the limitless power of the open data stack to work for you with DataStax Astra DB.