Why I Chose a Startup Over Amazon

When I was searching for my first full-time job out of school, I was set on moving to Silicon Valley – the land full of tech job opportunities. Out of the myriad of options available, I was purely focused on big corporations – Google, Facebook, Amazon, Microsoft, etc. I believed that these big companies had existing structures, processes, and systems in place to help me develop my career. While that was all true, I decided after spending 2.5 years at AWS, that I wanted to try a new environment – one that was a lot smaller and allowed for more cross-functional interactions. That’s why I joined LightStep as a software engineer – back when it was a 14-person startup.

My decision-making process

Being someone that over-researches all decisions in life, I listed out all the risks I was taking by joining LightStep. Now, almost two years later, I’m taking some time to reflect on my original list of risks.

Stability

Being a foreign national employed on a work visa, my biggest concern was stability. I wanted to minimize the possibility of losing my job and being forced to leave the country. During the interview process, I spoke to the co-founders extensively about our product-market fit, company vision, and more practically, our runway. Ultimately, I was convinced that LightStep would be a successful startup because of our developer-oriented product and our talented team. Plus, it wasn’t realistic for me to have “guaranteed stability” – every company, including big corporations, go through unpredictable changes like downsizing and re-orgs. In the end, I decided to focus on my own career development instead of blanket stability.

Work-life balance

Prior to joining LightStep, I’d heard my fair share of horror stories regarding life at a startup – late nights, stressful deadlines, and frequently sacrificed weekends for work. I knew these were possibilities at any startup, and I was ready to work hard. Upon starting here, I realized how untrue this was, at least at LightStep. We value a healthy work-life balance, and we all work hard while respecting each other’s time outside work hours. Our team almost never Slacks each other about work on evenings or weekends – with the exception of urgent production issues.

Chaotic work environment

Joining a tiny startup without much process and structure meant I was prepared for some chaos in my day-to-day work. I was both apprehensive about the lack of structure and excited about the opportunity to help improve the status quo as we grew. I have come to discover, over the past two years, that the “lack of structure” offered me more flexibility to work efficiently with cross-functional units of our company. As an engineer, I can communicate directly with sales, marketing, customer success, and recruiting – something rarely done at bigger companies due to compartmentalized departments.

Tooling

One thing I really enjoyed about my orientation at AWS was learning all the different tools that made engineers’ lives easier. Apollo, Amazon’s internal deployment engine, was so effective that it inspired the release of an external AWS product called CodeDeploy. Losing access to all these useful tools was scary because I didn’t know how our engineering velocity would be impacted without the proper tooling in place. LightStep’s monitoring and deployment system, even back in early 2017, was surprisingly sophisticated. I learned a whole new set of tools I had never heard of, most of them are open-source and created by other startups. I also learned to be “scrappy” – identifying gaps in our production tooling, researching existing solutions, and repeatedly trying them until I figured out how to integrate them into our environment. In a way, this experience makes me feel more “authentic” as an engineer because I now have deep insight into the part of our production system that was all a magic black box to me before.

Role Flexibility

As I mentioned previously, working at LightStep gave me opportunities to interact with people in different functions of the company. I realized over time that I was interested in problems beyond our technology stack, and I became interested in the engineering manager role. Luckily, at a startup of our size, I could switch roles in a careful, yet speedy manner. After I told my manager I was interested, the company helped me make the official transition to my new role, and I’m still ramping up on my new responsibilities. Stay tuned for future updates on my transition from IC engineer to management.

Come talk to us

Reflecting on my journey so far, I realized that while I was initially apprehensive about joining a startup, LightStep has proven to be a place where I can grow, work on challenging technical problems and still maintain a healthy lifestyle outside of work. If this sounds appealing to you, come talk to us or check out our open jobs!

LightStep [x]PM Releases Role-based Access Control

We’re excited to release role-based access control for LightStep [x]PM, with support for three different levels of permissions.

Administrators have the highest level of access, with organization management privileges that include creating, editing, and deleting users, projects, and roles.

Members have full access to [x]PM’s core features, which include viewing end-to-end traces and customizing dashboards, alerts, and Streams, but they do not have organization management privileges.

Viewers have read-only access to [x]PM’s monitoring capabilities – perfect for onboarding new users to [x]PM without disrupting existing workflows.

For more detailed information, visit our documentation page and log in.

Role-based access control (RBAC) vs attribute-based access control (ABAC)

When architecting access control for [x]PM, we evaluated existing industry-wide access control standards. The two frameworks we focused on were (1) Role-based Access Control (RBAC) and (2) Attribute-based Access Control (ABAC).

With RBAC, roles are created and sets of permissions for resources are assigned to each role, and users are granted one or more roles to receive access to these resources. For example, you can have a user that has the role “Member” which maps to a set of permissions like creating alerts, editing dashboards, etc. On the other hand, ABAC gives access to resources via attribute-based policies. ABAC policies are rules that evaluate access based on four sets of attributes including: subject attributes, resource attributes, action attributes, and environment attributes. For example, you could have a policy like “all users in engineering in San Francisco should have edit access to all dashboards.” Here, the subject attributes are {“group”: “engineering”, “region”: “San Francisco”}, the action attribute is {“action”: “edit”}, and the resource attribute is {“type”: “dashboard”}.

We decided RBAC was a better fit for [x]PM for the following reasons. First, the primary advantage of ABAC is the ability to support extremely fine-grained permissioning, which is overkill in our product as we have no need to control access based on specific user resources (e.g. Only employees in the HR Department who are located in New York can access this dashboard). In addition, ABAC makes it extremely difficult, if not impossible, to determine the permissions available for a particular user. Whereas with RBAC, it’s much easier to audit the set of users that have access to a given permission, and the list of permissions granted to a particular user. There is also less overall complexity with RBAC, because roles can be described by their names and are easier to visualize than policies. Lastly, the performance of authorization queries is better with RBAC, assuming the number of roles remains reasonable, because we don’t have to look up data required for a specified policy from multiple sources.

The major risk we found with RBAC was potential “role explosion”, which occurs when a huge number of roles are created to accomplish fine-grained authorization, resulting in slow lookup times and higher overall complexity. This risk is mitigated in our case, because currently our product only requires coarser-grained access control. In the end, the benefit of increased granularity provided by ABAC didn’t outweigh the cost of its increased complexity.

Mapping roles to permissions

Once we decided on using RBAC, the next question was how to map the list of available roles to authorization around our API access layer. One option was to assign API endpoints directly to each role, but this option was quickly ruled out because it would have left no room for us to extend our access control or API layer in the future. Tightly coupling the two means making changes to either would directly impact the other, a flexibility we did not want to lose.

We ended up going with a flexible permission model that introduces the concept of a “permission action”, which is an abstract, logical grouping of API endpoints. These permission actions are first-class citizens in our software architecture – all authorization systems communicate using them. Each API endpoint belongs to a permission action, and each role is assigned one or more permission actions.

LightStep [x]PM Role-based Access Control Data Model[x]PM role-based access control data model

The diagram above illustrates our RBAC data model where users have a many-to-many relationship with roles, and roles have a many-to-many relationship with permissions. Note that when performing an authorization check, we also confirm access to the API endpoint is permitted by checking the union of permission actions mapped to that user’s roles. This permissions model gives us the flexibility to support custom roles and extend our API layer in the future.

Try it out and share your feedback with us at support@lightstep.com.