We did. But the persisted data didn't live inside those ephemeral compute clusters though.
195 karma · joined November 29, 2019
A past team of mine managed services in a similar fashion. We had a couple (usually 2-4) single AZ clusters with a thin (Envoy) layer to balance traffic between clusters.
We could detect incidents in a single cluster by comparing metrics across clusters. Mitigation was easy, we could drain a cluster in under a minute, redirecting traffic to the other ones. Most traffic was intra AZ, so it was fast and there was no cross-AZ networking fees.
The downside is that most services were running in several clusters, so there was redundancy in compute, caches, etc.
When we talked to people outside the company, e.g. solution architects from our cloud provider, they would be surprised at our architecture and immediately suggest multi-region clusters. I would joke that our single AZ clusters were a feature, not a bug.
Nice to see other folks having success with a similar architecture!
But do we know how we that relates with other stuff like TV or videogames? It would be interesting to see a study comparing how they affect children growing up, or even adults.
This declaration came after Argentinian ambassor said, in a visit to Brazil, that there were plans to create it.
It seems to me that this is something that Argentina wants, while Brazil has no practical interest in it.
Worth mentioning that Argentina is a country that is dealing with deep financial crisis and heavy inflation and a common currency could help to reduce inflation. Brazil had similar problems through the 80's and 90's.
[0] - portuguese: https://www.cnnbrasil.com.br/business/nao-existe-proposta-de...
Will also take the opportunity to thank you for the message queues one, very good read!
Once you've created a few interview questions from daily problems, it also gets easier to spot good opportunities to do it again.
Haven't went through it in a while, but I remember only having a clear understanding of how Bitcoin works after reading it.
Most articles complain about the status quo but don't offer any practical advice. When they do, it is some approach that may not be an option on most cases - e.g. 40 minute interview followed by a 90 day probation period.
Live coding interview can be pretty tough for candidates, but we try to make a lit bit less difficult by:
- Giving them time and resources to prepare.
- Letting them use their preferred language and IDE/editor.
But since you have no control over format or time, maybe try to:
- Use reasonable problems - to assess skills people will actually need on the job. In our case it usually boils down to using comodity structures like a dictionary or map to do simple tasks efficiently.
- Use problems that start simple but can be extended. This is good because when candidates finish the first part, they get a boost in confidence. It is also nice because if they freeze, you can help them finish the current "level" and still have material to assess other skills.
- Set them up for success during interview:
- Reserve the first 5~10 minutes for introductions, ice-breakers or questions about the interview.
- Reserve the last 5~10 minutes for the candidate to ask any question about the company or the hiring process.
- Make clear that is OK to ask any question.
- Help them on small blockers.
- Be friendly.
Some links/references:
[1]: https://lawler.io/scrivings/erics-guide-to-hiring-software-d...
[2]: https://medium.com/@alexallain/what-ive-learned-interviewing...
[3]: https://www.holloway.com/g/technical-recruiting-hiring/about