Full Stack? From nothing to production

This post covers project and team maturity levels in Ve
By Diego Luiz Posted 14 June 2016

Full Stack? From nothing to production

Introduction

Hello, my name is Diego and I'm a developer at Ve. I run my own blog, and in parallel I will try to post here too. I posted the following article some time ago and I thought that would be nice to post it here too, as many things I wrote in the article I learned at Ve. You can find the original post here, however the content is the same as below.

Post

In this article I'm expressing my opinion about what is a full-stack developer and what it means for everybody (who has contacted me for this role). In almost all the places I read "full-stack", they mean someone who is able to do some Back-end + Front-end development, which is not wrong, but recently my responsibilities of my team inside Ve have expanded a lot, along with my understanding of what the process from requirements to having an application deployed in production. Many people I talk to, who consider themselves full-stack, consider it a "development job" which is done when you commit to source control, and then, magically, your code is running in production. What is wrong in my opinion, is that nowdays “full-stack” means someone who starts working even before the development starts, defining the architecture of the solution and sometimes even helping to define the product itself. You can see the topics I believe a full-stack dev should know, however they don’t need to be a specialist in all of them:

  • Pre development
    • Business Requirements
    • Solution Architecture
    • Designing Software / Database / Infrastructure
  • During development
    • Developing (Front / back end / Database)
    • Testing
  • Post development
    • Deployment (everything before)
    • Monitoring + alerting system
    • Metrics Alert
    • Logging
    • Escalating system
    • Scaling environment
  • In parallel
    • Infrastructure / Software Provisioning
    • Additional tools, like ChatOps, Continuous Integration, and so on...

I tried to separate the list into stages, however many of them can be done together. Each topic has an infinite amount of things to learn, and while it's not important to know everything, it is important to know what you can use and the trade-offs in using one solution / technology instead of the other. I can't really share my experiences for all of them, as I haven't participated in all the implementation, however I tried to get as involved as I could to learn about them. Let's try to dive a bit deeper into the topics:

Business Requirements - in the end, almost all developers have already helped to defined some business requirements. Some help with UX, others with systems workflows or infrastructure. It's very common to have developers, especially in more mature companies, involved in these discussions. In fact, the more people involved, the better, as a solid understanding of the business requirements will make it clearer to define the User Stories and Acceptance Tests.

Solution Architecture - Before writing a line of code, and after knowing what you need to achieve, you need to define what is going to be used and how. Usually this step is skipped in many places, as people tend to use what they are already using and jump straight into code. It's in this step you choose the technologies you are using, and it is here where experience shines.

  • C#, Node or Python for a X Scenario?
  • Let's go for PaaS ou IaaS?
  • Will the target computer be good enough to process this?
  • Is this technology easily scalable?
  • Do all the chosen technologies support each other?

Some real life examples:

  • C# is not supported by Storm / Spark (Apache data processing technologies), however if you use Azure, they made C# works with Storm, but not Spark. This you can find one the internet, but knowing the this actually works, and it works really well, only with experience.
  • PaaS is easier to deploy, usually cheaper, but until you need to do something out-of-the-box, there is a high probability that it's not supported.
  • Sometimes you need to opt for a lighter technology, or an older version because the target computer doesn't have the minimum requirements to run the application.
  • You just realise that your message queueing system is not easily scalable when it's about to blow, and everybody goes crazy.
  • You can have a brilliant idea to use a cutting edge technology, but when you test the support for the system's language, it's horrible.

Of course you can find all the answer on the internet, but until you know what you need to ask, you won't know what to look for.

Designing Software / Database - This is where the basic "full-stack" developer enters. Sometimes defining the software structure, database modelling, and so on.

Developing Front / back end / Database - Here is the main role of the developer. This includes all the good practices / methodologies / principles / patterns of software development. I won't go further because this is a huge topic.

Testing - This is not just the unit tests (which are covered inside the developing step), but the tests you run to guarantee your code is behaving as expected with other systems, aka Acceptance Test. Although this step is ignored in many projects (which I've worked), it's extremely important as it says if, in the end, everything works or not.

Deployment - This is beyond the basic "full-stack". This is what happens after your code is committed to the source control. Here you need to have a strategy and rules on how to deploy to the environments. Which environment comes first, and what to do if the last deployment failed? How do we synchronise the deployments of dependencies (which is difficult as hell), such as database, services, API's and infrastructure? How to deploy an updated service without making the down stream ones unavailable? In this step we begin to see the terms Continuous Delivery and Continuous Deployment, which many people are talking about recently. Beyond this comes the responsibilities that would be categorised as Operations, which most developers don't care about. Nowdays however there is drive for more sharing of responsibilities with the development team as well, creating the DevOps culture.

Monitoring + Alerting - It's highly recommend, if not mandatory, to have something monitoring your system. With monitors, you then can configure alerts when the system is behaving incorrectly. Monitoring systems have evolved a lot, and today they need to be as reliable as the product itself.

Metrics - Sometimes some weird errors happen and they don't crash your application, but instead change the behaviour, consuming more memory, cpu, or varying the throughput. This is where metrics come in, feed values to the monitoring system. You can set alerts to be triggered when something unexpected happens, and the metrics can be used as a base for business / technical decisions.

Logging - Generating logs should already be done in the Developing step. However it's normal for a company to have 100+ servers now, and when a website throws a 5xx error and there are 10 servers behind a LB, finding the logs is complicated. Today it's really important to centralise the logs and make them searchable using something like the ELK stack.

Escalating - This is a very interesting system, which I've never used unfortunately. Let's imagine that your website is offline, what does your monitoring system do? Send email to 100 people and make they crazy? Send email to 1 person and pray for the person to read it? There are some tools you can integrate with your monitoring system to try to reach out a person, if there is no reply, it calls and sends text message, then tries to reach the next person and so on... So you can trust that someone is going to answer the phone when something is wrong.

Scaling - Most websites have a predictable amount of users / sessions / requests, and the peaks are not so extreme. But when you have completely unpredictive traffic, you need your system to be able to scale up and down on the fly. This way your business doesn't lose money because you lost users, and you don't spend money with unused infrastructure.

Infrastructure / Software Provisioning - With the cloud, hardware is being handled the same way as software. You define it as scripts, commit to source control, and deploy your virtual infrastructure to your virtual datacenter, maybe using a CD implementation. After this, you can have some software provisioning running which installs everything the machine needs according to its role. This is taking the infrastructure management to another level. I'm going to leave some links of some nice tools which I've used/heard about.

Note - I'm not posting anything related to code on purpose, as I will do it in other posts. This list is not separated nor does it have any descriptions, if you want to know more about the tool, click on the link.

Currently, I'm doing my own full-stack process, trying to cover as many areas as I can. So soon, probably, there will be a post here and in my personal blog about it.

Cheers :)

Diego Luiz
Diego Luiz
Software Developer