
I just pushed out some pretty significant updates to the way that we build our code at Subeta, which is pretty cool and should make the site a lot faster and quicker to respond when lag starts.
TDLR: These changes will make Subeta more secure and faster by ensuring we have the most up to date software running all the time. It reduces the amount of work that I have to do to bring new servers online, and more intelligently determines when new servers are needed. Yay!
Immutable Infrastructure Immutable infrastructure is one of the big 'buzz' words ? around the technical community today, and it's pretty simple. Previously we'd build a server "image" with all of our configurations on it that had the version of PHP we wanted and all of the other things we needed. Then we'd download our code from github, and bam, there is Subeta. There are a few problems with this method, our server images tend to get out of date because they require me to go and manually update all of our packages, update the operating system and kernel, and then make a new image. This can sometimes be a multi-hour process and tends to get left at the bottom of priority lists. A lot of times, speed and security patches take weeks to get bundled into our image. Now when we push code to the site it kicks off Amazon building an image immediately with updated security and speed updates.
Less managing for us One of the goals with sysadmin'ing is ensuring that we're managing the least amount as we possibly can, all the time. In our current state, we are manually managing each of the application servers. Part of that is the above process (which is a pain) but also includes ensuring code updates make it, configuration for when the server boots up, bundling our code, pulling from github, managing dependencies for PHP. The new system handles all of that through a simple set of files that we can check in to our code.
Better monitoring and server spinning We also currently manage when a new server gets brought up, or taken down, based on a series of "alerts" (like high CPU). This is a process that we've built ourselves and has been rough in the past, especially when new events start. Now it uses a series of sophisticated alarms based on a number of inputs (cpu, latency, I/O) and can more easily bring up a new server. More importantly, when it does it kicks off the server building process and ensures that this new server has everything it needs to start running from the second it gets added to the load balancer versus our current servers which can take 5-10 minutes of setup before being healthy.
? :
💖 ✨ 🤗
BUZZ BUZZ BUZZ buzzwords
that is all
🐝 ☕ bug (he/him) | your friendly neighborhood code wrangler. stay in the loop! join and check out the latest admin post highlights