StationOps

This tweet is funny, but it highlights a problem that can easily hold up a major customer deal. If your biggest prospect asked for technical due diligence tomorrow, what would they discover that you should already know? If you're a fintech selling to larger customers, some of the requests are fairly predictable. Architecture diagrams, security policies, penetration test results, where customer data is stored and who has access to it. Depending on the customer, they might also ask for ISO 27001 certification or a SOC 2 report. But the questions can go quite a bit deeper. For example: - When was the last time you actually restored from a backup? How long did it take? - If the engineer who built your infrastructure was unavailable, could someone else recover the service? - How do you prevent one customer from accessing another customer's data? Can you demonstrate that it's working? - Which third parties have access to customer data, including support tools and subcontractors? - If a customer leaves, how do they get their data back? What happens to copies in your logs and backups? - Were the issues identified in your last penetration test actually fixed and retested? There's a big difference between having a policy that says you do something and being able to demonstrate that you actually do it. And these aren't necessarily things you can sort out in a few days when a prospective customer asks. It's much better to find these gaps internally than have a potential customer discover them halfway through a deal! --- If you're a fintech preparing to sell to larger customers, DM me or reach out to StationOps. We can help you review your cloud setup and identify gaps that could become a problem during technical due diligence.

The infrastructure engineer is on holiday, how much work will have to be put off until they return? An engineer who was on leave for ten days said that when he returned he was informed the team was "dead in the water" without them. For years they have been requesting coverage and their colleagues have already been receiving training. There was not going to be any further appointment in the field of infrastructure. You have to make a decision: who is to carry out the essential work and what will you agree to take off their workload so that they can learn it? The engineer who is teaching them also needs time for that. First, find out where the difficulties still lie. The team should select one task that depends on that engineer, for example, recovering a service, and then decide who will take responsibility for it. Get that person to go through what they would do, using the instructions that the team already has; let the engineer hear it and take note of where they need to provide help and keep it as a conversation without making any changes to the production. You could come across a missing access permission, instructions that omit a step, or a change that has to be approved by someone who is likewise away. Next, decide which person is to deal with those problems and include the work in the team's plan. It involves working out what other things can be put off. If all the people concerned still have the same amount of work and the same deadlines, you'll probably be having the same discussion again before the next holiday.

If your customer numbers doubled, do you know how much your cloud bill would increase? Ensuring your cloud bill doesn't eat into your margin is essential, check out our latest blog to make sure you don't fall into the usual traps. https://lnkd.in/dFHep95Q

If your customer numbers doubled, would your cloud bill double too? Ask your team 3 questions: 1. What is driving our cloud bill? 2. What are we paying for whether customers use it or not? 3. If customer numbers double, how would usage and our cloud bill change? A useful cloud metric as customer numbers grow is cost per customer. Is it trending down? That can help improve your margins. Or perhaps cost per transaction is more useful, depending on how people use your product. However, don't make the mistake of treating your past average cost as a prediction. Some parts of your cloud bill will grow with product use, but others will stay flat until you have to increase capacity. Better to estimate what it will cost to support the next stage of growth. Knowing where those jumps could happen can also help with your growth and pricing plans. Could you name the biggest driver of your cloud bill without looking it up? Get in touch if you'd like help working through the numbers for your cloud setup, we can do that at StationOps.

Most engineering teams don’t end up in cloudops chaos because they made one terrible decision, it usually happens over the course of months/years. You add terraform because it makes sense, then monitoring, then security tooling. Then a few scripts, some manual checks, a release process, a devops hire and eventually a whole load of things that only one or two people really understand. None of those choices are inherently bad and most are completely rational at the time. But put them all together and you get an operating model where every infrastructure change needs specialist knowledge, releases start depending on the same people and product engineers spend more time thinking about cloudops than they ever should. I think the uncomfortable truth is that a lot of teams don’t actually have a cloud tooling problem, they have a cloud operating model problem. That’s a big part of why we built StationOps. Not because devops needs another dashboard, but because product teams shouldn’t have to become infrastructure companies just to run their software properly. The shift we believe is coming is from cloud infrastructure being a specialist function that sits beside engineering, to a managed capability that the whole product team can rely on with automation where it makes sense / guardrails built in / senior cloud engineers when judgement is needed and a lot less tacit knowledge holding the whole thing together. Our vision is pretty simple really. Running production cloudops should feel boring. Not because the work is easy, but because your team shouldn’t have to feel the complexity every day.

CloudOps is as fundamental to software as software development itself. The decisions made underneath the product shape how safely the team can ship, how quickly issues get resolved and how much confidence there is in every release. That was central to our work with Flexiwage. As the platform grew, they needed a stronger operating foundation for payroll-critical services, compliance, incident response and cost control. Over six weeks, we redeployed their entire infrastructure, put SLOs around the payroll pipeline, automated audit evidence and introduced clearer incident and cost-management processes. This is what we mean when we talk about CloudOps as a core engineering discipline. It has a direct impact on the product, the team and the pace of delivery. Full case study: https://lnkd.in/dK_dwVAZ