Cloudhealth Technologies (www.cloudhealthtech.com) is the leader in cost usage and reporting for the cloud and on-premises infrastructures. Cloudhealth is transforming how businesses save money and take control of their infrastructure.
Our stack is a mixture of angular, ruby, java, scala, and spark with a lot of interesting data engineering and data analytics problems to face. We're migrating to a microservices model using kubernetes and kafka as a bus for services.
Please let our recruiter Dave Aquilino ([email protected]) if you're interested, and he can follow up with you!
Cloudhealth Technologies | Software Engineer | Boston, MA | Onsite
Cloudhealth Technologies just closed our Series D round of $46M. We're the leader in cost and usage reporting and optimization for AWS, Azure, GCP. We've recently GAed a product for Datacenter, too.
Our stack involves ruby, java, scala, spark, and angular. We've got thousands of customers worth of data and interesting problems to solve.
* Do they have their own projects or do they contribute to others?
* How interesting are those projects generically and in the context of what I would need this developer to do?
* Are these projects actually used by anyone? Are there pull requests, etc?
* Does the developer actively keep working on existing projects or move around? I.E., are these learning vs hobby vs commercial?
* How is their readme? Does it exist? Is it sufficiently complete to convey meaning?
* How is the code organized? Is it reasonably laid out? Do they make use of third party packages and tools? Does it seem like they are re-inventing the wheel?
* Does the code work?
* Is the language chosen the right language for the job? Are they using idioms of that language or more generic ways of expressing loops, vsriables, etc.?
* How extensible is their design? Does it feel krufty or is it a pleasure to read?
* Is the code novel? Are they re-inventing the wheel or are they actually fulfilling a need?
* Are their projects wide and varied in scope and tools?
Those are a few things off the top of my head. Not an exhaustive list.
Cloudhealth is the leader in infrastructure cost and usage optimization. Our products span across AWS, Azure, GCP, and Datacenter. We do the heavy lifting of analytics around what your cost and usage means split across business units, regions, availability zones, time, and many other dimensions.
We're working with spark and EMR to process terabytes upon terabytes of information. We have a ruby-based application layer which presents to angular, and we're rapidly ramping up our development team to make major improvements to our platform.
If you have a passion in backend or frontend engineering for improving small to Fortune 500 size businesses, Cloudhealth could be the place for you!
We offer all the usual perks of free stuff, food, commuter benefits, and otherwise. The engineering team here has a lot of engineers who have been working in industry for decades with a combination of less experienced software engineers creating our next generation environment.
Please feel free to email me at johnm at cloudhealthtech com if you're interested!
Cloudhealth enables company's to take control over their cloud usage! We're the leader in programmatic cost management and a provider of resource monitoring to help identify areas where our customers can improve their infrastructure.
We're looking to hire developers of any experience level that are dedicated to taking on complex challenges in a fun, upbeat environment.
The Bureau of Labor Statistics (http://www.bls.gov/) is just fascinating enough and just badly organized enough that I never seem to be able to get to the same useful piece of information twice. And thus I constantly find myself looking at other interesting facts about the US labor force.
I know it was a younger time back in 2006, but there is always something disingenuous about referring to the entire class of software developers being unable to do good frontend UI/UX development. It's a different discipline to be sure, but it's not a lot different to me than saying knowing statistics to be a good data software developer or any other application development. Software doesn't get written for its own sake.
I am contemplating a move from Github to Gitlab right now. Feature-wise there seems to be enough parity with Github to make this sort of thing possible.
Also, gitlab's CI system is attractive and being able to run our own runners in our own environment (we currently used an outsourced CI system.)
We're also doing it because Github enterprise is too expensive, and we want to rely on less external dependencies in our environment.
As for prove, I mean you can't just make crap up and pretend it's true. Your points are more logical than his for your use cases.
http://aws.amazon.com/ec2/previous-generation/ -- you have to use a different page. I guess in SSD-land commodity drives versus normal drives don't change much since you're trapped by the number of writes. -- My point about disk sizes is he says something unequivocally: that only i2s have SSDs. He doesn't qualify it. And that's bad netizenship and wrong or whatever. :)
You are probably right for big, cheap SSDs and fast networking GCE likely is the place to be. It's a newer stack. But this article fails to prove that, and it provides a lot of FUD.
"Local SSD storage is only available via the i2 instances family which are the most expensive instances on AWS" - He didn't say BIG. And gp2 is actually pretty good in my opinion. (Also, you missed the now legacy hi1 instance in your list.)
Just for completeness I give you other problems in this article. I run a moderately large AWS workload, and there are definitely problems with AWS, but this article missed many of them and feels like a rant more than something with veracity.
1. "Add 10% for dedicated instances" - but he never brings up a competing product on GCE. There is another simple way to getting a dedicated instance: launch the largest instance type in a class, and you have dedicated hardware.
2. "Add 10% on top of everything for Premium Support (mandatory)" - Simply wrong.
3. "We are forced to pay for Provisioned-IOPS whenever we need dependable IO." - This was true 5 years ago. I'm sorry, gp2 is a fine service which runs great.
4. "Local SSD storage is only available via the i2 instances family which are the most expensive instances on AWS" - Wrong as stated above which you didn't even refute. You just put parameters on a use case.
5. "An unplanned event is a guaranteed 5 minutes of unreachable site with 503 errors." - This is certainly hyperbolic. I've sat down with the ELB team, and we've hashed through this. We had an ELB that ramped up to 600,000 rps everyday with massive spikes in that ELB's performance. They offer pre-warming as a convenience, but it's hardly necessary. The worst case scenario would be some number of 503s for some amount of time up to a maximum of 5 minutes. How does GCE perform? No answers given.
6. "All resources are artificially limited by a hardcoded quota, which is very low by default. Limits can only be increased manually, one by one, by sending a ticket to the support." - This isn't true in GCE? Of course it is. There isn't infinite infrastructure. The AWS limits are published, and they are kept low so, for instance, it would be difficult for a developer or a malicious user to run up a giant bill for you. Learn to plan.
7. "There is NO log and NO indication of what’s going on in the infrastructure. The support is required whenever something wrong happens." - Cloudwatch anyone? It gives pretty decent instrumentation of, for instance, your ELB. What does GCE give him? Not mentioned.
8. "We have to comply to a few regulations so we have a few dedicated options here and there. It’s 10% on top of the instance price (plus a $1500 fixed monthly fee per region)." - Amazon was a first mover in this space. I think this is a shoehorning of something that is complicated and manual on their side. What does google offer, I repeat?
9. "A reservation is attached to a specific region, an availability zone, an instance type, a tenancy, and more." - This is garbage. You can change reserves between availability zone and instance type (within a family of instances.) Moreover, you can sell your reserves. I agree vaguely this is effort, but it's minor effort that's generally solvable with a mild amount of planning.
10. "The discount is small." - It's like 40-70%, he quotes 30% on GCE.
11. "AWS Networking is sub-par" - I actually agree with this, it feels like an aging infrastructure, but I imagine it's something they will address.
Most instance types you can launch with ephemeral disk that is local SSD. All recent generation servers are like this. m3s, etc. You don't need to launch an i2. There are a lot, lot of problems with this article.
The day unit is not the only unit in play. I split my week up this way, where I try to keep one day in the business schedule and four days in the maker's schedule. Unfortunately, as my career has progressed I've started putting two days into the manager's schedule and three days into the maker's schedule, but I find this a highly effective partitioning scheme. You have all your coffee meetings and whatnot on a day of the week of your own designation.
Full disclosure: I work for a company that does user acquistion for applications.
That being said, we got into the business because an app the company had invented was too hard to market, so we started marketing apps. There are a lot of techniques in this space -- some low budget, some high(er) budget. Happy to chat if you like. Feel free to dm me @jtm on twitter.
Although I don't know Kelly Ellis, I believe this is in reference to this: https://plus.google.com/+KellyEllis/posts/L4wawXpNt25 -- I am not actually trying to express an opinion on this, but that's the context from yesterday.
Senior Devtools Engineer - Boston
Engineering | Boston, MA, United States
Fiksu is the leading provider of mobile app marketing products that help app and game marketers reach their user acquisition goals. The company’s patent-pending Programmatic Mobile Demand Platform applies intelligent technology to proprietary big data to master ALL the challenges of mobile advertising - including tracking, optimization, media buying and integration. Additionally, Fiksu offers FreeMyApps®, the world’s largest app discovery platform where users are rewarded.
Fiksu is a 200+ person company headquartered in Boston with offices in Northampton, MA, San Francisco, London, Helsinki, Singapore, Seoul and Tokyo. Voted Boston's Best Places to Work in 2013, Fiksu offers competitive salary, equity and benefits. By joining Fiksu you would not only directly impact the success of our business but also help to shape the mobile landscape of the future.
Are you a developer who doesn’t feel comfortable with their responsibility ending at the code? Are you a systems administrator who prefers coding their way out of a problem?
Job Specifications
Spend 30% of your time developing automation and tools to support 50+ developers and thousands of nodes processing billions of transactions a day.
Spend 30% of your time digging deeply into the infrastructure and remediating problems around availability, reliability, scalability, and efficiency.
Spend 30% of your time growing the platform through researching and implementing the best services and tools.
Job Qualifications
Either experience in Linux systems administration with a desire to increase your knowledge of development or experience as a developer with a desire to learn the best practices of systems automation.
Knowledge of the modern stack including the utilization of external caching, load balancers, internal caching, queuing, webservers, SQL and/or NoSQL databases, and cloud services.
Familiar with an automation framework such as Chef, Puppet, Ansible, or otherwise.
Worked with AWS and their APIs or equivalent (such as OpenStack or CloudStack.)
Experience with Ruby and/or Java (but other languages work, too.)
A desire to teach developers about new tools, technologies, and methods for improving their throughput.
Job Benefits:
Fiksu engineering embodies the cultural movement known as devops. Developers release their own code, manage their own monitoring and alerting, and are the first line of support to triage their software.
Intelligence and dedication are valued at every level in Fiksu, and this fosters a community of curious learners willing to share their knowledge and collaborate on solutions.
Join the startup that BBJ voted #1 Best Place to Work!
I am an injured crossfitter. I herniated my L4 vertebrae's disc, and I will likely never be the same. That being said I also used to be a 305 pound man who became a 192 pound man on Crossfit and its concepts. I have never been a "zealot" but I do have some problems with this article.
My problems with this article are multiple, but the big glaring one which people seem to be repeating here over and over again are that Crossfit level 1 certified coaches only "spend a weekend". They make it sound like these people literally came off the street never having done Crossfit before and got certified that weekend.
Maybe that's true. But I've never met a person who took the level 1 let alone became a coach at a box that didn't already have a good chunk of time actually doing WODs and improving from them under their belt. They have gone through the discipline in their own practice and have decided coaching that would be something useful for them. Unlike NASM where you can read a book and get certified, there is a hands-on/lab teaching component. This should be lauded. And no, not everyone is a great teacher, and the best judgment is on the community to determine if someone is working or not. (I've seen Crossfit instructors be dismissed from boxes.)
I would like the OP to quote some articles and provide some science around why the Crossfit HIIT/circuit style training is actually dangerous. I understand the concept, that when in fatigue doing additional work is dangerous, and that Crossfit encourages this at some level, but it's always on the discretion of the participant to put the bar down, to stop doing the pull-ups, and to stop where they got to that session in a WOD. The real challenge in Crossfit is not to leave it all out on the floor, it's to know when to stop leaving it.
What Crossfit does that I see a lot of personal training and individual training programs neglect are concentrations on proper mobility, warm-up, and form. And this comes from a guy who started Crossfit basically near the worst possible shape you can.
Another thing is I was able to study for a year+ with a multi-year Crossfit Games placing athlete, and they used Crossfit WODs to train. Pretty much exclusively. The volume was amped up for sure, but the same movements and the same formats. Maybe the really, really successful people don't do that? But the interviews I see with Rich Froning and Mikko Salo tend to basically say they do three workouts a day in the crossfit-style format. Metcons, endurance, strength. Oh well, I'm late to this party, but my $0.02.