The software development industry has evolved to a point where a “mix-and-match” mindset is essential to creating truly unique applications and platforms, leaving development teams to change the way they think about technology stacks.
What Drives Changes to the Software Architecture Stack?
Improving the efficiency and effectiveness of your software development team comes down to one question with two parts — how can you save developers time while also reducing risk?
We’ve come a long way from the days that we had to run Ruby on Rails on our own computers, communicating through SQLite to avoid the memory and space challenges of running MySQL on a local machine.
The shift to a virtualized environment via Vagrant allowed us to provision virtual machines and set up Linux boxes to run applications locally against an environment similar to the production environments, even from our MacBooks. The overall result? Easier processes for our developers with reduced risk.
Today, and to save our developers more time and reduce the deployment risk, we’ve moved to a modern DevOps processes, using Docker to enable Continuous Integration, Delivery and Deployment. Because Docker can save the state of the OS running an application we’re developing as an image, we don’t have to worry about dependency risks anymore as we mix and match libraries on Mac, Linux or another development environment. What we develop against is what is deployed and what runs in test and eventually production environments.
However, Continuous Integration, Delivery, and Deployment are just pieces of the software architecture stack improvements. Over the last several months, we’ve come to understand more about how we can rethink the architecture stack and better serve clients.
Expanding Our Software Architecture Stack Perspective
When we talked about an example software architecture stack in December, this is the stack we came up with for our platform projects:
- Based on the Node.JS runtime environment framework
- PosgreSQL and Elasticsearch for a relational/non-relational database
- Hapi.js on the backend
- Ember.js for the frontend
While this example stack has served us well for certain software/hardware platform and Internet of Things (IoT) development projects, that doesn’t mean it’s the only stack we can use for any project. The technologies we’ve worked with are too varied for us to have such a strict view of the software stack:
Various Node.js backends: Express, Hapi
iOS application development: Swift and Objective C
Android application development:
REST services using .NET Web API 2
Various other technologies:
Working with all of these different components have led us to understand that a mix-and-match approach to the software stack is the most effective way to meet specific project needs.
New Experiments Have Shaped Our Mix-and-Match Mindset
Succeeding with both of these frontend platforms has reconfirmed that software architecture in general and the software architecture stack specifically isn’t about determining a single set of technologies for every occasion. It’s not about saying “we have Node.js on the backend working with Ember on the frontend and that’s how we’re going to build our applications.”
Instead, we have become better at mixing and matching the technologies to address the specific problems for a project. For example, with today’s technology and DevOps processes, you can build API stubs for the frontend without worrying about the backend—you’ll eventually just plug in whatever backend that works best for the project.
Whether you’re using Angular 2, React, EmberJS, or any other technology, you have to make sure you’ve set yourself on the right path for end-to-end product development. If you want to learn more about what’s necessary for a complete product development process, download our free ebook, The End-to-End Product Development Guide.