Changing almost as quickly as the tech industry itself are the tools engineers use to support their companies.
We connected with developers from four fast-growing engineering teams to learn what their current tech stack looks like, what they like about their toolkit, and how they go about evaluating new tools to adopt. Here’s what they had to say.
Bo Li, a software architect for cybersecurity firm Ping Identity, walked us through their ranking system for selecting new technologies to implement. Li said the most important thing to keep in mind is a system’s flexibility when it comes to quick changes.
Design a system that is flexible enough to allow quick technology changes when needed.”
What does your tech stack look like these days?
APIs are served up by our Spring Boot-based microservices in Docker containers that run on Kubernetes. At the data layer, we use a mix of Cassandra and PingDirectory for persistence and Kafka as the event bus. We also use some AWS services including ElasticCache, SNS, SQS, and KMS. The frontend are all React-based, single-page apps using OpenID Connect for authentication and authorization. Lastly, we use DataDog, New Relic, and Spunk for monitoring and alerting.
What are some of your favorite facets of it? How do you choose what tech to use to complete a project?
I love the decoupled nature of a microservices architecture and how it allows us to independently and quickly deploy small changes without risking the entire system. When evaluating new technologies, the approach we take is highly dependent on the use case. We usually rank them in terms of performance, scalability, robustness, and cost followed by PoCs in the lab. I think what's more important is to design a system that is flexible enough to allow quick technology changes when needed.
Beth Richardson, an application architect at Blackbaud, highlighted their office’s leniency on shared infrastructure tooling and libraries to speed development and learning across all of their teams. When it comes to new tools to use, Richardson said it’s a team decision.
When [we] select a new tool to solve a problem, we first pull a research story into a sprint to evaluate multiple options.”
What does your tech stack look like these days?
In the Austin Blackbaud office, our engineers are fullstack and building microservices using Spring Boot Java and gradle builds, with tests written in Groovy using Spock, and frontend in Typescript using Angular, with tests written in Jasmine and Protractor. We use messaging to transfer data and events between services and NoSQL and SQL datastores, depending on the use case.
What are some of your favorite facets of it? How do you choose what tech to use to complete a project?
I really enjoy working with Spring Boot in general, and our tooling and shared libraries that make the best use of what Spring has to offer. Working with Spring libraries is always a great experience as the engineers who write that code obviously take pride in their work — just like the engineers on my team.
In general, when my team is selecting a new tool to use to solve a problem, we first pull a research story into a sprint to evaluate multiple options. Usually this research would include investigating what other teams at Blackbaud have used to solve similar problems and the pros and cons of other tooling solutions. We then evaluate the cost required to implement and maintain each option before making a decision as a team on what we want to move forward with.
Lead Software Engineer Tom Nolan said Keller Williams’s tech stack provides his engineers with the opportunity to experiment with new technologies and work independently. Here he describes the team’s “use the right tool for the job” mentality.
[Our] approach allows our teams to operate independently and deploy on their own schedule without conflicting with others.”
What does your tech stack look like these days?
With regard to our UI, we utilize React in combination with Next.js in order to break down our monolithic front-end application. This approach allows each of our teams to operate independently and deploy on their own schedule without conflicting with others. Our cloud services are written in a combination of Go, Node, Java, and PHP using a microservice architecture. More recently, we’ve begun taking advantage of GraphQL and Apollo in order to build out our data graph and simplify our development workflow.
What are some of your favorite facets of it? How do you choose what tech to use to complete a project?
One of the greatest benefits of the current stack we use at KW is it allows our engineers the freedom to enhance their skills by experimenting with and utilizing modern technologies. This freedom is a direct result of the “use the right tool for the job” mentality. Since the industry is new and evolving, more powerful tools are constantly being released. That flexibility allows us to keep up with trends that give us a competitive edge.
Yousef Elreda, a principal software engineer for ClearDATA, shared the health tech firm’s tech tools but emphasized that it’s not so much the solutions that lead to success as it is the people operating them. Describing his team as “magical,” Yousef said it’s the interactions between one another that lead to the best productivity output.
We are happy to bounce ideas off of each other, trash them, and start over.”
What does your tech stack look like these days?
We use AWS, Google Cloud, and Azure, and programming languages like C#, Go, Python, Node.js, Typescript, Javascript, and the various testing frameworks that come along with each. We use both SQL and NoSQL solutions, servers and serverless. We of course use Git and have code reviews and coordinated release cycles.
What are some of your favorite facets of it? How do you choose what tech to use to complete a project?
My favorite facet is the interactions with the people that I work with. Having healthy interactions during design will materialize into products that are successful, make our customers happy, and make healthcare better.
Conversations that start with “what if” instead of “we should” are the better conversations. We are happy to bounce ideas off of each other, trash them, and start over. We get to the most righteous solution given our combined experience and intuition.
When we choose a tech stack, we start by asking ourselves what the right solution for the customer is. We have teams that gather insights and feedback from customers. We then determine what the experience of the team is, and finally pick a stack that gets us faster to a quality solution. We are not afraid of changing our mind, and iterating, and we are constantly learning and using new technologies that best fit our desired outcome.
