At Forter we develop an online, low latency fraud prevention service. We started out with a single real time system, but as throughput increased, we gradually decided to offload more and more jobs to run periodically. This varies from sophisticated anomaly detection systems to detect new types of fraud, to
Do You Trust Your Front-End Tests as Much as We Do?
Do You Trust Your Front-End Tests as Much as We Do?
Consider the following scenario: A critical bug has been detected on your web application overnight and a fix must be deployed quickly. How fast can it get to production during off hours?
How much do you trust your tests’ coverage? How
Walkthrough: Tracking an Elasticsearch Java Client Sniffer Bug
Elasticsearch has always been good to us at Forter. It’s truly reliable. It’s damn good at searching, and it’s a solid distributed application as well. It balances a cluster relatively quickly, and it is easy to configure and easy to backup/restore, etc., but… we were haunted by an issue which
Can we agree on Dependency and Version Management ?
Purpose of the game
Get your team engaged in a heated debate about an opinionated subject
(in this case Versioning and Dependency management)
Setup
- Two groups of developers sitting around a table.
- A Judge that is very opinionated about the subject. The more controversial the better.
- A Host that can handle a raging
The Evolution Of Web Data Binding
Have you ever talked passionately about data binding concepts with a backend engineer? I have, and most of the time they look at me as if I were a caveman who doesn’t speak their language… so for all you cavemen (and backend engineers) out there… Let’s get some
0Flake – Reaching Reliable Non-Flaky Tests
Testing Philosophy
Tests provide confidence. They provide confidence during development, in new deployments, and continuously in production (monitoring). Flaky tests, on the other hand, fail or pass for the same configuration, and
Security 101 for SaaS Startups
Things I wish my first boss had told me
So you are working at a startup, and you have been wondering at what point should you start looking into security considerations and compliance? Which technical debt should be postponed for a later stage, and which systems should be hardened this instant? What are the main considerations?
Technical debt gets piled up, and in many cases it is easier to pay later rather than now. For example, if you are using ElasticSearch without username/passwords, you should double check your firewall settings. After round-B your startup would probably have the manpower and budget to properly secure the ElasticSearch cluster.
Startup culture is a bit more difficult to change "later". Let's take a trivial example. Developers that are used to pushing code without code review, would complain that peer review would bog down the development, and it might even smell "too corporate" for them.
So which security considerations are relevant at an early stage?
What security concerns were raised by customers willing to pay for your product?
What are the security expectations in your industry (Medical, Finance, Enterprise)?
What are the target market (country) regulations (Data Privacy, Data Residency)? Europeans are known to have tougher regulations. Different US States have different regulations.
Which tools and policies would not hurt your team's morale.
How long would it take you to prepare a security risk plan (see example at the bottom of this document)?
What is the impact of Intellectual Property theft, business plans theft, bitcoin/ec2 theft, losing all your data ? How would it affect your sales, customers, investors?
How can you protect against a data breach?
How can you reduce the exposure after a data breach?
We grouped together the expected security recommendations by the different phases a start-up goes through. The more money and data the startup handles, the bigger the investment in security:
SelfConf: empowering group learning for software engineers
Did you ever attend a talk – in a conference, a local meetup or simply listening to an interesting podcast on your commute to work – and felt so inspired, that you couldn’t wait to get back to work and try it out?
It rarely happens, but I’ve listened to some
9.5 Low Latency Decision as a Service Design Patterns
A few hundred milliseconds latency is achievable for a complex fraud prevention system, but with very little wiggle room. In the past two years, we have selected a few design patterns that have helped us achieve our latency goals, using standard technologies used by most SaaS companies (load balancers, queues,