Hopefully, during the course of their career, every engineer gets to work on a project that’s being written from scratch.
It’s a time where, as a younger developer, I would rush into things, using the tools I already knew but (hopefully) in a more sophisticated manner.
Now I see it as an opportunity to employ new technologies and languages, to broaden my horizons. I also find myself considering the pitfalls and strategies of orchestrating an application’s development from whiteboard to production.
I’m currently architecting an IoT RESTful service that will back a customer-facing energy dashboard and receive telemetry from hundreds of thousands of devices in the field. I will be using the Spring microservices architecture and two databases, one SQL and one non-relational.
Some design considerations are:
- Environment (cloud vs hosted)
- Continuous Integration (Jenkins vs TeamCity)
- Service Registry (Eureka vs Consul)
- Centralized logging (ELK stack vs Loggly vs Fluentd)
- Load balancing (Netflix Ribbon vs NGINX)
- Containers (VMs vs Docker vs Kubernetes)
- NoSQL database (Time Series Database vs HBase vs Cassandra vs MongoDB)
Starting this early in the SDLC has given me some perspective. Cooking from scratch is definitely a taller order, but like i said, it’s also an opportunity for learning and making mistakes and becoming a better engineer.
Taking on the role of architect, I find myself faced with more abstract concerns:
- Scaling
- Economy of environment and dependencies
- Following the crowd vs going proprietary
- Testing procedures
- Change control and release process
- Documentation
- Rapid prototyping
- Fail fast
- Fault tolerance
- Monitoring
- Alerting
- Supportability
- Flexibility of application
- Open source vs paid third-party software
- Choosing the tool with the biggest user base vs the one that best fits your needs
- Overinvesting in a platform or technology
- Deferability of features to a future version
- Outsourcing part of development
- Logical segmentation of architecture
- Development timelines
- Premature optimization
This laundry list, all these things need to be given attention because the worst time to screw up a project is at the beginning. If there are flaws in your design at conception they will snowball into larger ones down the road.
I now have much greater respect and sympathy for the people whose work I’ve derided at when it fell into my lap. Needless to say, next time I inherit a codebase I won’t be so quick to judge.
(image from https://adiscussiononhope.wordpress.com)
Leave a Reply