The Dell Cloud Manager engineering team is growing.
In this gist, I want to give you an idea of:
- Who we are looking for
- What we work on
- What your tools, process, and daily work would be like
- What your next step would be to get in touch
Right now we are looking for a Java and Python developer with REST experience and an interest in cloud computing APIs and open source. You could have experience with just Java, just Python, or both.
We're distributed across the world - so one of the main things we prize is good communication.
We value diversity, a nonjudgemental atmosphere, and irreverent but respectful attitudes.
Caring about code quality and tests is important. And we have some nice tools in place to help (more on this later).
Caring about the customer experience and having empathy for users is important.
Cloud computing experience is not required in all cases, but an advantage.
Do you want to work remotely? Our group's headquarters is in Minneapolis, MN, but most of the engineering team works remotely. So that's an option we can discuss. Everyone gets a development laptop (MacBook Pro or Dell+Linux), but remote workers are also sent two widescreen monitors.
Do you live outside the U.S.? That's another thing we can discuss. One of the many advantages of being part of a large company like Dell is that we are set up to hire all over the world if it makes sense. We currently have remote employees in the US, New Zealand, Canada, the UK, and Ireland.
Dell Cloud Manager (DCM) is an application that allows users to deploy and manage applications across different clouds but also weaves in important but often missing things like access controls and budgets.
We've released a brand new version of the webapp, here is a glimpse:
It's the culmination of significant user research/testing as well as insights gained from talking to our customers.
Developers here get exposed to a wide variety of functionality and challenges. The system auto-scales applications, automates operations on the cloud instances (e.g. user addition), integrates with configuration management systems like Chef and Puppet, and talks to systems like SAML and LDAP. Under the covers we are often optimizing databases and API calls, working on fun concurrency issues, or refactoring things to make testing easier or to bring a new feature online.
The new webapp is built with AngularJS. This makes REST calls to a distributed system of JVMs that forms the core application. Along with responding to on-demand calls (both from Angular and from users integrating via our API), there is also an asynchronous task system that is making calls out to the clouds (and a wide variety of other things).
All communication with the clouds is built around an open source cloud abstraction library called Dasein Cloud. Dasein Cloud is developed collaboratively with outside contributors and is fully open source. It's a powerful library that keeps our core code clean and cloud-agnostic. For more information and to find the code, check out the Dasein Cloud Wiki.
We also recently open-sourced Blockade, a utility for testing network failures and partitions in distributed applications that is built on Docker.
Most people use OSX for development, but we only deploy to Linux. We use recent MacBook Pros with ample RAM (Linux is also supported if you prefer). We use git and GitHub for all repositories, the open-source and private ones as well.
You can develop purely locally. The entire distributed system can even be built from scratch and launched via Vagrant with two commands. This is the real system, fully configured. This setup allows you to work on things completely speculatively, attach remote debuggers, and make whatever changes you want without affecting anyone. And since you are using the same build tooling, Chef code, and launch paths as the QA and release processes do, you can have confidence things won't get weird later.
We have a formal QA team, process, and continuous integration setup.
We communicate using Slack mostly, and integrate with a lot of other development and deployment tools (including some custom integrations).
There is an informational side to this, for things like commit and test notifications the messages show up inline:
There's also a control plane side to these integrations where you can tell bots in the room what to do for you. For example we can comment on tickets inline with the chat.
We make tests run against any pull request (PR) that is submitted, and Jenkins will annotate the result. This saves the code reviewer time by giving them confidence that things are not hosed before digging in. It's also very easy to launch an instance from the PR in order to more deeply review prospective changes.
I could go on here, but I mainly wanted to give you a sample of the kind of tools and time-saving processes we have built. And we're always looking to do better.
Sound interesting? The next step is to start a conversation. Send an email to engineering-careers@enstratius.com introducing yourself, tell us what you are interested in, and attach your resume.
Looking forward to hearing from you!