The Dev-X Project is a series of features with industry leaders sharing their developer experience insights. In each “episode”, we ask an industry leader 10 questions about DX, collect their responses and insights and share them with you.
In this episode, we sit down with Hila Fish - Senior DevOps Engineer @ Wix.
Hila believes that DevOps carries the vision of enhancing and stabilizing a company by taking care of its infrastructure, and allowing the business to perform at its best.
In her spare time, Hila is a lead singer of a cover band and gives back to the community by co-organizing DevOps-related events (including ”DevOpsDays TLV” & ”StatsCraft”), mentoring through courses and communities such as “Baot” (Women in tech engineering Israeli community), and generally sharing her passion and knowledge whenever possible.
You can follow Hila on LinkedIn and Twitter
When did you decide to become a developer?
I’m not a developer per-say :) I’m a DevOps / Infrastructure Engineer / SRE - Which has its developing aspects in it.
When I was 12, I carried around floppy disks and installed software and games to my friends’ computers. My brother introduced me to this world, and I knew I’d stay in it as much as I can :)
After my somewhat brief army experience as a helpdesk technician, I knew I wanted to deepen my knowledge and practice in systems, which led me to become a system admin/engineer, and later on a DevOps Engineer (And while “DevOps Engineer” is more of a culture than an actual job description, I consider myself an Infrastructure Engineer/SRE).
What are the key ingredients to a really good engineering culture?
You say ingredients, I say values ;)
Collaboration - You need to collaborate with others to surface the best solutions, and to make sure the end goal is achieved.
Professionalism - Always think about the company’s needs. This should apply to every aspect of your work.
Integrity - If you think something is not right - speak up. Processes can and should change and evolve for the better.
Communication - Share your knowledge and explain why you went with x and not y. That way people can learn from you and adopt your best practices and your unique line of thinking in their day-to-day as well.
There are more, of course, but I think this covers the core of it.
And while being technical is great and even necessary, training your business mindset would really help create a culture where preference is not given to only the most technical solutions, but rather to the solutions that help achieve the best outcome for the company.
Let’s say you’re building something from scratch. What does your ideal stack look like?
I’ll focus on the infrastructure side of things since this is my forte :)
When thinking of infrastructure, there are 4 pillars that come to mind:
Infrastructure creation: I’d use Terraform, probably, but depends on the use case. If other developers need to use it as well, then perhaps Terraform wouldn’t be my first choice. In that case, I’d probably go with Pulumi (I haven’t worked with it yet, but I like it as an option).
Configuration Management: I’d probably go with Ansible, but Chef is still here and there’s probably a reason for it, so I’d check that out as well before deciding.
Monitoring: The go-to is Prometheus and Grafana, but I’m starting to hear more and more about VictoriaMetrics and its flexibility, so I would definitely consider and play with it before reaching any final decisions.
CI/CD: You can say a lot of things about Jenkins, but it is a flexible tool that allows more than just CI/CD, so I’d probably stick to that.
As for the infrastructure itself, I’m more familiar with Kubernetes but that doesn’t mean it’s always the best solution. Focus on the company’s needs, remember? So I’d need to think about what is best for the application, and not only about what I prefer to work with.
So I would juggle between Kubernetes, Serverless (Lambda and the likes), or standard VMs. It depends on the use case and the application needs.
Tell us about an epic engineering fail you’ve experienced in your career. What did you learn from it?
One time, I worked on a Linux server that had Jira installed on it, and made it crash. I thought that “oh well, it’s just Jira, people will wait a bit to open tickets and update on statuses” but apparently this Jira was utilized by the DevOps team back then for critical flows.
So I learned not to assume things - to ask if a maintenance task can be done (or coordinated) and to understand what should be taken into consideration while doing that.
I also learned to always communicate intentions to work on X or perform maintenance on Y because then it could surface concerns or other things you didn’t know about that could have an effect on your plan to do that X/Y.
I’m not sure if that’s considered “epic” or not :)
But I do remember a case in one of my previous companies where a team member accidentally deployed a patch to all production databases at once, making all of them restart and basically generating a full-on downtime on all services.
I don’t know what he learned from it, but I learned not to have a light finger on the trigger. And if there it is possible to set up precautionary measures to prevent human errors, then I should do that with high priority. One small example is a pipeline I created in Jenkins, in which one of the fields was free text, so I added some checks on the pipeline to make sure the user inputs the necessary text to prevent any failures.
How important is “Developer Experience”? Do you see this as a trend that will evolve into dedicated teams/functions for mainstream tech companies?
I already see this being evolved into dedicated teams. In Wix for example, there’s a “DevEx” team that is responsible for the Developer Experience.
I think it’s crucial to think about Dev experience because the company can’t exist without a product. The product gets created by a developer. If their experience is the best possible - then the product releases will be frequent, the overall ability for disruption would be higher, and employee preservation would be optimal. In fact, one of the reasons I left a previous company is because the platform I worked with was problematic, not idempotent whatsoever, and it frustrated me to work with.
Let’s take the mono-repo question once and for all - should you ‘go mono’?
I can understand why developers like mono-repos (shared libraries and dependencies and all), but from my standpoint as someone who needs to maintain them - permissions wise, CI pipelines wise - it introduces more complexity to the extent that I’m not sure the tradeoff is really worth it.
So I would prefer to not go down the Mono-Repo path, but.. :)
What will be the hottest dev trend/adopted technology in the next 12-24 months?
Lately, I’m hearing a lot about 3 things:
- Chain Supply attacks and products to mitigate them
- Cost Management challenges
- DevOps Enablement - Tools to help my day-to-day (Kubernetes schema validations, introducing policies to Terraform and Kubernetes, etc)
So I think that we’ll be seeing technology to deal with all of these things.
Some claim that front-end developers will become irrelevant in the future of no-code tools. Do you see this happening? If so, how soon?
It depends. No-code means Yes-style? :)
We need people because people have a sense of style and aesthetics.
So even if no-code tools can help with the logic side on the front-end, the visual side - in my opinion - would still need a human touch to it.
Share some tips to help remote teams collaborate better.
Zoom should be utilized properly: too many Zoom meetings can be exhausting and too few Zoom meetings can lead to an inability to progress on tasks/progress because we need other people’s inputs. So we need to understand that Zoom should be utilized efficiently, and not be pushed to a limit where someone would say “I had enough of Zoom for today” and decrease their overall productivity for the day/week.
Communication is key: Even if you don’t need something from someone - reach out and put yourself out there. And if you do need something - We live in an async world. Don’t just send “Hey” to a person on Slack and wait for their response.
Instead, send out “Hey, I hope all is all well on your side, I need help with…” and dive right in, covering the most needed details (too much data can be overbearing as well) to get to a resolution/progress.
If there are teams in different time zones: Send out a summary of issues/updates so we can be updated without compromising our early mornings/late nights just to be present (by Zoom, not necessarily by mind) on sync meetings that aren’t really comfortable for all sides due to timezone differences.
Do you want to share anything else? Please share anything you think would be of value to the broader developer community:
There’s a lot of information out there - unsorted, raw, without deriving conclusions.
Sharing your knowledge is important and could lead to a lot of great things - Improving your online presence and personal brand, helping others achieve something (How many times you’ve googled “How to…?“. Why not become one of the search results? :))
And also, be humble. Even if you’re a senior expert in your field, be open to accepting different approaches and lines of thought. This will make you more accessible and make people want to work with you and value your opinion. It will also allow you to learn. I believe we can learn from anyone, junior on their first day or a product person with a different view (business mindset for the win) or anyone else.
Do you have DX wisdom to share? Apply to get featured in an upcoming Dev-X Project episode.
