A lot has changed since we wrote about an example software architecture stack last December. At that time, we were weighing the differences between known technologies stacks such as LAMP, WINS, and MEAN. While our original example stack strayed from these standards, today’s software architecture demands call for greater change.

If you liked this article, listen to Dialexa’s VP of Software Engineering, Andrew Turner, on Custom Made talk technology reliability and security and how in today’s current landscape CIOs won’t get promoted if everything works. But they will get fired if anything doesn’t: Listen to all episodes of Custom Made for insights and perspectives from industry disruptors and technology leaders.

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 technology 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 technology 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

Various modern JavaScript frontend: Angular (we are on Angular 2 on most new projects now), Ember, React

iOS application development: Swift and Objective C

Android application development: 

REST services using .NET Web API 2

Various other technologies:
Ruby on Rails, Python, PHP, etc


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

In recent months, we’ve experimented with Angular 2 and React as frontend options for our development projects. While Angular 2 and React are both JavaScript frontend options, React derives from the Facebook library whereas Angular 2 comes from a Google/Microsoft collaboration.

Without diving too deep into the technical differences between the two JavaScript frontends, we’ve found that some of our platforms run best on the varied React libraries while others benefit from Typescript approach from Angular 2.

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.”

Our End to End Guide to Product Development

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.

While we’ve generally settled into either a Microsoft stack or a Docker JavaScript based stack, the statement we made back in December has never been truer—it’s not about using what we’re comfortable with; it’s about using the right tools for the job.  Don’t go looking for a nail just because you have a hammer in your hand.

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.

Click to Comment