What’s This ‘Full Stack’ Thing?

This website references the term 'full stack' on a fairly regular basis. We talk about it because we think it's important and we think it is an attribute of Scale Abilities that sets us apart from our competitors (we do it well). So what is it?
The stack in question is the technology stack. It is made up of all the components that contribute towards a 'business application', such as the database, the middleware, the application, and so forth. Each of those components are made up of many more sub-components, further breaking down the technology into its constituent parts. For example, the 'database' is usually made up of

  • Some kind of storage
  • A storage network
  • Servers
  • Operating systems
  • Storage software
  • Database (physical implementation)
  • Database (data model)
  • Database (SQL & PL/SQL)
  • Local Area Network

In a commercial business, one or more of these components maps to a team or team member. In a large enterprise, there will be at least one team for each of these components. The stack continues into the middleware:

  • Some kind of storage
  • A storage network
  • Servers
  • Operating systems
  • Connection pools
  • Middleware & components
  • Framework
  • Application
  • Wide Area Network

Again, one team or team member per component part. This is a classic 'divide and conquer' approach to the technology stack. It allows each portion of the stack to be well serviced, without distraction, by a dedicated resource. Unfortunately, this also leads to an increasingly common phenomenon: Boundary Problems.

A boundary problem is one where the root cause of a real issue cannot be determined by looking at just one portion of the stack. For example: One screen of the company website is taking 30s to respond. Is this a database problem, a storage problem, a network problem, or perhaps an application problem? It could be any or all of those problems, but it is just as likely to be a combination. The application might be only retrieving 30,000 rows from the database, and the database might be servicing that query very quickly. The network also looks good, with 1ms response times. But the application is fetching one row at a time because of the processing model used within the application. 30,000 times 1ms=30s. What's the fix? In this case, it's probably to rework the application to fetch in large batches, but exactly whose radar did this show up on?
Another example: the application is running slow; the DBA says the storage is slow and the storage admin says the storage is responding quickly. All the business knows is that the application is slow, and nobody knows what is wrong.
These problems are but two examples of a boundary problem, an impedance mismatch across layers of the stack both technologically and in human terms.

Scale Abilities recognised this problem many years ago and has invested in building experience across all the layers of the stack and learning the different languages used by the respective teams. We are good at solving these types of problem quickly, candidly and without political acrimony. We can prevent such problems from emerging in the first problem by getting involved in the architecture, design and development phases of projects.

If you are experiencing problems of this type, why not contact us for an initial opinion on whether we can add value to your project?