So you started working on or about to start making your first web app? Great. There are a lot of guides on how to build the application and handle some of the trickier aspects on the actual application. The impetus for this video and article is that I have not seen too much info on what you need to do for a reliable and scalable deployment once your application is ready to go live.
Dan’s Rule of DevOps #4: Everything is a product of its environment. How and where a project is built influences the result as much as the programmers.
Because most first time applications are built on a small number of developer computers and tested on commodity hardware or cloud services, they tend to expect things that are not desirable when used in production. The big ones are:
- The application is designed to only run one copy of itself at a time, preventing a way to do maintenance without shutting things down
- They write data to a local filesystem instead of consolidating storage in either a network-accessible database or object storage
- They expect configuration files rather than taking config from the environment or a config provider
- The application hac access a lot of the network and file systems, allowing security incidents to escalate
In order to prevent these issues, we need to do a little planning on these 4 areas:
- Architecture - what are we using to host and serve the parts of the application
- Security - How do we protect ourselves against malicious and accidental loss of data and good will
- Deployment - Making it easy for developers to write, test, and release the app onto the big-boy hosting system
- Monitoring - Continually checking that everything is working, auto-fix what it can, and yell when it can’t
Architecture
Your architecture is one of the leading factors in how reliable, performant, secure, and cost-effective your deployment will be. It is critical that you get this correct.
As you can see from the above diagram, there are many, varied ways to get the same application on-line and ready to serve pages. How you decide to build out will depend on what your application needs from a code level, what staff you have and their combined expertise, your expected scale, and your requirements for security and reliability. The earlier you can nail this down, the fewer limitation you put on the final architecture, and generally the lower you can get the costs.
Additionally, you need a good idea of the size you are targeting for the initial system. Both over- and under-building will cause you massive pains either by bleeding out money or by not being able to handle the load. My rules for sizing your initial system:
- Figure out your break even points for number of users and revenues (track them on a dashboard).
- Target that size, plus an order of magnitude (generally, the first order of magnitude will be non-profitable, the second and third should be). Be aware that “freemium” sites need more users that you might expect.
- Size systems to the break-even scale.
- Allow yourself to dynamically add resources to expand.
Security
Any web system will be constantly under attack from opportunistic adversaries. Bluntly, these are the people that go around joggle door handles to see if anything is unlocked. When you start out, these will be your primary problem. Your job is to keep them out, and make it hard for them to do anything if they do get in.
Your application will generally be built on personal computers, and not on cloud hardware. This leads to the developers validating the software on personal computers. Developers have full access to their computers and network resources(as they should) which means that the software they are running will (usually) have full access.
That’s bad.
For security, everything running in prod has to be strictly limited to its intended function. A program that can access any website, is a single exploit away from costing you huge hosting fees for data transfers. A machine that allows you to write and execute files to the file system is at risk of having an attacker load their wared onto your stuff.
Continuous Deployment
As we mentioned above, the deployment environment will usually not match what your developers are developing on. To make their lives easier we need to setup systems to:
- Track contributions and changes to the code
- Allow for this new code to be tested
- Ease deployment to multiple environments for testing and public release
Continuous Integration/Continuous Deployment (CI/CD) systems do that. They start with a code repository that holds your code changes, and a build process that will perform tasks like building and testing your code. Once it passes tests, you can have it deploy the code to an environment that properly replicates what the final production environment will look like so you can truly know how it will run and also find the gotchas that come up when things are developed on full-access computers.
Monitoring
You can’t fix what you don’t know is broken.
Monitoring is the process of pulling information while your application is running and using it to predict and detect failures. Some things you need to monitor:
- Business events like sign-ups, revenue changes, and cancellations
- Basic metrics like how much CPU/Memory/Disk is use
- Bad logins
- Response time to your application
What you monitor is very custom to your application, but it’s important to know what’s important to keep your application “well-fed” with what it needs to continually get out there and bring in them monies.
Conclusion
Hope this was useful info.