- Worked on Dreamscape Network
- Worked on Prometsource
- Worked on Juwai
The time I joined Onerent Inc. is actually my first jump from a corporate setting (enterprise scale) to a startup environment. And just like any other newbie, I was fascinated how things are run "the startup way".
Execution is important, speed is everything...
So the whole idea of startup is moving workloads into sprints where we treat everything as moving parts -- it's all about how much time you'll be able to release something for your product or service.
While we push for speed, observing quality is something we didn't take for granted. Trust me, we move fast and take marginal step to avoid massive breakdowns.
How do we make sure we got everything covered from development, to deployment, to production releases, to regression?
As I mention before, we trust we hired the right people, thus, first-principle thinking is what we follow inside the engineering workforce. Now, making sure that the testing ground for everyone's code is in good state, embracing devops will be a key component in cultivating the engineering culture.
Devops, in a sense of:
- TDD is applied
- CI/CD is applied
- Boxing Environments is applied - Separating Staging, Beta and Production
- Staging - Code Testing for Developers (pre-deployment state)
- Beta - All sorts of testing for QA Engineers (PR merged to master)
- Production - Code passed QA and now ready for the release
- NOTE: Theses environments have a production-like setup, this way, we know that if something doesn't work in staging -- it will not work on production. Same as if something works in production, there's no way it will not work on staging/beta. The only difference between these systems is the data it's reading and database it's connected.
- Centralized Access is applied
- Everyone is free to play on the Staging server (SSH access allowed with sudo permission). This is to avoid bottlenecks and overhead.
- Restricted Beta/Production environment. ACLs are configured.
- Automation is applied
- Heavily utilizing Ansible playbooks to everything in operations
- Post-mortem is applied
- We talk things out. We improve our process if we spot an area that needs more muscle or brain. We make sure we won't commit the same mistakes as we believe that -- once is enough.
While not everyone loves to write, it's important that as a Devops Engineer, you encourage people to document what they are doing. This is the only way for you to enjoy vacation without being called for an issue. Documentation saves life!
Speed is the priority.. next to security
When we apply speed in whatever we do, it's normal to say that not everyone will be able to manage the workload overnight, especially for those who are new to the startup mechanics.People need to pick-up the slack and navigate through the shallow waters of opportunity. Everyone in the team needs to know that time is the greatest opponent in building the next big thing for your market. Reminding everyone, that there are other players trying to acquire more market share overtime is vital -- it's an advantage when everyone is in-sync and on-track.
How do we observe security within our work?
- Using of password manager within operations
- Each services, servers are running it's own AWS IAMs with specific ruling to a particular service
- We separate internet and intranet
- Internet is for public access
- Intranet is only accessible via Office Network or VPN
- This mostly applies to our development and beta environments, including internal tools
- We implement jumphost
While it's hard to influence everyone in the organization to adapt to best practices to better observe security, as a devops engineer, it's your duty to set the standards and never get tired of reminding them about it.
So startup's greatest advantage is always, speed!
