Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Amazon S3 is keeping Ukraine’s data safe, we ask if Windows Presentation Foundation is dead, and developers tell us why they switch jobs. (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Home working is ripping the heart out of cities, the DoD’s bizarre cloud strategy, and Apple adds a $10,000 app price option. (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week, four things that caught my eye from Amazon Web Services’ re:Invent 2022 conference: SnapStart turbocharges Lambda, Graviton3E ARM HPC SoC, AWS continues hiring, and AWS’s origin story. (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week, a remote/hybrid work special: Bribes to relocate you, Fridays are forgotten, and big tech firms stop building offices. (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Apple lets devs increase subscriptions “without consent,” Twitter has more than 19% spam accounts, and we dig into the claim that Microsoft is about to double salaries. (more…)
You can find plenty of high-level definitions out on the internet about what site reliability engineering means and what site reliability engineers do.
But if you want to understand what it’s actually like to work as a site reliability engineer, there is perhaps no better source than job descriptions. SRE job ads explain what real companies are looking for and what they expect on a day-to-day basis.
To provide insight on what SRE looks like in practice, we’ll look at some job ads from several leading companies. As we’ll see, each company has a slightly different take on what the site reliability engineer role entails, but it’s possible to identify some core themes that underline what businesses expect.
To understand the content of SRE job descriptions, let’s examine examples from four leading companies.
GitLab’s SRE job description contains most of what you would expect from a typical site reliability engineer job ad. It highlights the importance of having a mix of technical skills and collaboration skills. It also emphasizes expertise in areas like Unix/Linux, infrastructure-as-code and Kubernetes.
What may be slightly surprising, however, is the emphasis that GitLab’s job description places on programming skills. GitLab expects SREs to know how to code in specific languages, like Ruby and Go. The takeaway is that SREs need to know more than just how to use code to solve IT operations problems. They must also be able to develop applications or contribute code to application platforms (the job description mentions “contributing to code in GitLab” as a required SRE technical skill).
Also interesting is the fact that GitLab expects site reliability engineers to be able to write blog posts. Blogging may not be one of the first skills that come to mind when you think of a site reliability engineer’s responsibilities, but at GitLab, at least, it’s part of the job.
LinkedIn provides an SRE job ad template that businesses can use when posting their own SRE jobs on the site.
LinkedIn’s ad is pretty high-level (which is unsurprising, given that it’s a template rather than an ad for a particular job). For the most part, it doesn’t mention specific tools—although the main exception is programming languages, where it says SREs should know how to code in languages like C, Python, JavaScript and Ruby. Like GitLab, then, LinkedIn clearly sees development as a core SRE job responsibility.
The LinkedIn job description also places a heavy emphasis on the ability to “gather and analyze metrics.” It doesn’t use the word “observability,” but that seems to be what LinkedIn is getting at.
Continuing the theme of development-centric SRE work, a recent job ad for a specific SRE opening at Microsoft reads a lot like a DevOps engineer job description. The ability to “design, write and deliver software” is the top responsibility listed in the ad, which also mentions familiarity with CI/CD tools.
The Microsoft job description also mentions the importance of written and verbal communication skills. Unlike GitLab’s ad, this one doesn’t say SREs will need to write blog posts; still, it’s clear that companies expect people in this role to be creative communicators in addition to technical experts.
It’s worth noting, too, that Microsoft wants site reliability engineers who know both Windows and Unix. If you need further proof that Unix skills are absolutely central to SRE work, look no further than this job ad from the company that created Windows.
Even Amazon—a company that is more of a platform provider than a software vendor—places major emphasis on the ability of SREs to code in one of its recent SRE job ads.
Interestingly, the Amazon job also highlights networking skills as a major qualification. That’s understandable given the complexity of networking in the AWS cloud. But it’s a bit surprising because most other site reliability engineer job ads don’t call out networking expertise as a key skill—despite the fact that network engineering is critical to SRE work.
The Amazon job description mentions the importance of an applicant’s willingness to be on-call, too. We suspect that’s critical in virtually any SRE job, but at least Amazon is upfront about the fact that, at time, you’ll be woken up at 4 a.m. to manage incidents.
There are a few key takeaways from these various SRE job descriptions.
This is not to say that all SRE roles are identical or that all companies expect the same things from their SREs, of course. But the jobs ads or templates we’ve surveyed do highlight how the high-level understanding of SRE translates to on-the-ground reality at actual companies.
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Three things that caught my eye from Amazon Web Services’ re:Invent 2021 conference: Private 5G, Graviton3 chips, and something called DevOps Guru for RDS (yes, really).
First up this week: AWS Private 5G is a new turnkey service, offering local private cellular data infrastructure, for places where Wi-Fi just doesn’t cut it. Despite the name, it offers a 4G/LTE fallback to 5G/NR. Because it’s AWS, the hardware is free—you just pay for usage.
Wi-Fi is unreliable and low powered. 5G over the 3.5 GHz “citizens’ band” seems like a great alternative (just don’t tell the lunatic fringe of the anti-5G brigade).
And, of course, AWS makes it easy to buy—Amazon ships you all the private radio gubbins for “free” and just bills you based on capacity and usage. It’s automatically configured and remotely maintained. You just take your internet connection and plug it in.
Aisha Malik: Amazon launches preview of new AWS Private 5G managed service
“AWS Private 5G” … is a new service that aims to make it easy to deploy and manage your own private network. … AWS CEO Adam Selipsky said that with AWS Private 5G, you can set up and scale a private mobile network in days instead of months.
…
There are no upfront fees or per-device costs: … Customers pay only for the network capacity and throughput they request. [It] scales capacity on-demand.
…
AWS Private 5G is available in preview in the United States.
And this is better than Wi-Fi how, exactly? Ballu counts the ways:
Industrial area coverage: Where you need 50 Wi-Fi radio units, you can provide service with 3–4 p4G/p5G radios.
…
Hazardous areas: Where you can’t provide the networking at all the corners or areas, one p5G radio blast area (esp with beam technology) can.
…
Packet loss: Less packet loss compared to Wi-Fi (believe me, it’s a big deal in the Industrial world)
…
Compatibility: What’s a negative for 5G modems (not many devices are available), is positive to some extent. Once investment is made with 5G modems, the devices can be on the road too.
Unsurprisingly, Brian Roemmele feels vindicated:
Precisely as I wrote about in 2017 to great ridicule from an analyst at a famous VC firm: Amazon is becoming a phone company.
…
From the Sidewalk Network to the Kuiper satellite system to local 5G. The network is no longer just “dumb pipes.”
Graviton3 is the latest version of Amazon’s ARM server chip. It looks like it’s based on a 5nm process implementing the latest ARMv9 ISA. AWS is making the usual claims about it being much faster than the previous generation, but it also has new security features.
AWS is deadly serious about low-power, high-performance compute. Amazon is just one licensee that would be distressed to have Nvidia owning Arm.
As I said last week—and the week before that—ARM chips are an increasing fixture in the datacenter, especially ones that value “performance per Watt.” Other IaaS providers might bleat about how they’re reducing the energy used to cool their data centers, but surely it’s a better plan to start with less waste heat.
Maria Deutscher: AWS debuts new compute-intensive and AI instances powered by custom chips
AWS’ new Amazon EC2 C7g instances target compute-intensive workloads such as analytics tools and scientific modeling software. The C7g series is based on the AWS Graviton3 chip, the third iteration of the cloud giant’s internally-designed processor.
…
Companies that plan to use C7g instances for machine learning workloads can expect an up to threefold performance jump in AI performance. The speed jump is partly the result of the processor’s support for bfloat16, a specialized data format [that] enables applications to process floating point numbers faster and using less memory than FP32, the data format historically used for the task.
…
For cryptographic tasks, Graviton3 delivers as much as double the performance of the Graviton2. … The chip introduces a feature called pointer authentication to reduce the risk of cyberattacks.
Tim Anderson has been sifting through the re:Invent announcements:
Top of the list perhaps is Graviton3, the next generation of AWS’s homemade [ARM] server processors. These chips will be used in new C7g instances previewed offering DDR5 memory (50 percent more bandwidth than DDR4) and up to 25 per cent better compute performance compared to instances powered by Graviton2.
…
Adam Selipsky gave his first Re:Invent keynote as AWS CEO. [He] said Graviton uses “up to 60 per cent less energy.” … Graviton matters because it is among those leading a charge to get more [ARM] microprocessors into data center and cloud infrastructure, and because if it’s more energy and cost efficient to operate, it’s critical to Amazon’s bottom line, sorry, today’s environmental concerns.
And is that pointer-authentication feature useful? Yes, very, says spijdar:
Very useful. … If the performance is good, this is a nice extra layer that makes return-oriented programming more difficult. Combined with NX bits, it really raises the difficulty in developing/using many types of exploits (it’s not impossible to bypass … but there’s no perfect security).
DevOps Guru for RDS is the latest upgrade for AWS’s oddly-named smart monitoring features.
Laplace and Gauss were right: Your DevOps team aren’t all rockstars. “Average” ops staff are in the majority. So extending AWS’s monitoring automation to your database instances should be a positive step.
But that branding: Can anyone take it seriously?
Stephanie Condon: AWS brings more automation to database management
The new Amazon DevOps Guru for RDS automatically can find and fix database issues … helping developers using Aurora detect, diagnose and resolve database performance issues. [It] can help remediate a range of issues, such as over-utilization of host resources, database bottlenecks, or misbehavior of SQL queries.
…
Last year, AWS introduced DevOps Guru, a service that uses machine learning to automatically detect and alert customers of application issues. … Amazon DevOps Guru for RDS builds on that
…
Users can view [issues] in the DevOps Guru console or via notifications from Amazon EventBridge or Amazon Simple Notification Service (SNS).
Sounds interesting, says u/random_dent:
I thought the DevOps Guru for RDS sounded interesting. You need to enable performance metrics first, which have their own charges, but it still looks not too expensive, plus three months free-tier, so we may try it out.
We’ve had some odd issues with RDS performance that are too inconsistent to lock down. It would be interesting to see if this could give us some insight.
But that name! Here’s Thomas LaRock—@SQLRockstar:
I’m old enough to remember when DevOps Guru for RDS was just called “database performance monitoring.”
And @shmick is young enough to say it like this:
such a cringe name
You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.
Image: Andrew Svk (via Unsplash)
Amazon is placing its bets on the future of cloud. The announcement that CEO Jeff Bezos will be stepping down and passing the torch to Amazon Web Services (AWS) leader Andy Jassy at the start of Q3 2021 signals a major shift in the future of technology – and not only for organizations specializing in IT, storage and web hosting. Rather, the growth of AWS signals a multi-industry-wide demand for cloud services as the new normal for conducting business – and those that continue to rely on legacy technologies could soon see their businesses falter in the shadows of competitors in the near future. However, every company’s individual systems are entirely unique, and modernization doesn’t happen with a one-size-fits-all approach. So why should organizations invest in new technologies – and how?
The pandemic has made painfully clear the need for organizations to get away from their aging legacy systems and to embrace the cloud for a variety of reasons. First, COVID-19 has forced almost all businesses, across all industries, to embrace more distributed networks – requiring business-critical systems and functions to be accessed from countless different sources at any given moment. This can prove a major pain point for organizations with IT infrastructures that are prone to difficulties and outages. These shortcomings can have a detrimental impact on customers and citizens, as well. In light of major IT outages in states like New Jersey, California and Oregon, it’s clear that pursuing a more modern approach to IT systems is no longer just an option – it should be the only option. This is because, in addition to the benefits for users and enhanced business function, there are added benefits for the company itself and the world at large.
Shifting systems away from data centers requires significantly less energy to power – and as data centers are responsible for as much greenhouse gas emissions as the airline industry, the environmental impact coupled with operational cost savings enable businesses to meet customer demands for greener practices while reducing overall operational costs. What’s more, this change to cloud services will allow for horizontal scalability within organizations, ensuring that businesses are able to meet demands for their offerings in real-time.
If your organization is relying on a mainframe, it won’t be able to reap the many benefits that cloud infrastructure has to offer – and organizations that shy away from making these vital updates run the risk of running their business offline entirely. As a result, the time to act is now – but in the rush to get IT departments in order, it’s vital that organizations choose a modernization strategy that is best suited to their unique business. For most organizations, a modernization journey begins with one of the four following approaches:
Amazon’s shift in leadership is a testament to the growth potential and overall importance of the cloud – not only for companies that manage web services, but for all industries around the world. However, by proactively taking the steps to move away from legacy systems and pursue a cloud-first approach to business, organizations will be better positioned to maintain their revenue streams, improve scalability, drive customer satisfaction, reduce operational costs and even protect themselves from potential disasters down the line. By setting and sticking to a set strategy and timeline for modernization, companies can ensure the success of their most mission-critical applications and functions to ensure their continued success and survival in a world or rapidly changing business demands.
The sky is the limit – are you ready to aim for the cloud(s)?
Amazon Web Services (AWS) is always busy introducing new services, enhancing existing ones and, quite often, driving trends. However, the cloud services provider has upped its game even more in recent months.
In the first half of 2020, AWS announced an astonishing number of developments that enable technology interoperability, simplifying legacy feature removal, creating greater flexibility and time-savings for developers and putting new capabilities at users’ fingertips.
You are going to be hearing a lot about ARM processor architecture and not just because the chipmaker is being acquired by Nvidia, the leading maker of GPUs.
Developed in the 1980s, ARM processors are finally hitting their stride as companies are embracing ARM-based chips. ARM-based processors combine high-performance RISC designs, lower manufacturing costs and reduced power consumption, making them ideal for portable devices such as smartphones, tablets and even laptops. More and more companies are designing processors that implement ARM architecture, including Apple, AppliedMicro, Broadcom, Qualcomm and Samsung Electronics. This year, Apple brought ARM chips into the desktop world with tailored extensions such as a built-in security enclave, a motion co-processor and a neural engine.
AWS is among those embracing ARM architecture, which has led to introducing an array of robust services that will benefit developers and end users alike. Case in point: This summer, AWS announced the general availability of its sixth generation of Amazon Elastic Compute Cloud (Amazon EC2) instances, including general-purpose (M6g), compute-optimized (C6g) and memory-optimized (R6g) instances. Powered by AWS-designed, ARM-based Graviton2 processors, they deliver up to 40% better price/performance over comparable current-generation x86-based instances.
They also offer 50% more NVMe SSD storage GB/vCPU over comparable x86-based instances. The local SSD storage works well for apps that require high-speed, low latency storage, as well as for temporary storage of data such as batch and log processing, and high-speed caches and scratch files.
They’re ideal for workloads ranging from application servers, microservices and high-performance computing to CPU-based machine learning inference, electronic design automation and gaming. Numerous organizations have already successfully adopted ARM-powered instances and are realizing price/performance benefits.
The AWS Graviton-based instances are supported by a broad ecosystem of operating systems and services from independent software vendors (ISVs) as well as AWS. They can be purchased as on-demand, reserved, or spot instances; covered by savings plans or as dedicated hosts/instances, and support up to 19 Gbps Elastic Block Store (EBS) bandwidth.
The AWS Graviton2 processor itself, released in late 2019, deserves recognition, too. Compared to first-generation ARM-powered Graviton processors, they provide twice as fast floating-point performance per core for scientific and high-performance computing workloads. They also offer optimized instructions for faster machine learning inference, always-on fully encrypted DDR4 memory and 50% faster per core encryption performance to further enhance security.
A number of AWS services, such as Amazon Elastic Load Balancing, Amazon ElastiCache and Amazon Elastic Map Reduce, have realized superior price/performance in testing and will be moving into production on Graviton2-based instances.
AWS isn’t the only organization opting for ARM. As many others prepare to make a move, AWS is doing its part to facilitate the transition. That includes deploying services that streamline various aspects of the app development process, in keeping with the efficiencies and increased performance offered by ARM-based chips.
One that we’re most excited about is AWS CodeArtifact. This fully managed software artifact repository service eliminates the need for setting up, operating and scaling the infrastructure required for artifact management. It works with commonly used package managers and tools such as Maven and Gradle (Java), npm/yarn (JavaScript) and pip/twine (Python), so it can easily be integrated into existing development workflows.
AWS CodeArtifact can be used for creating centralized repositories for sharing software packages approved for use across development teams. Its integration with AWS Identity and Access Management (IAM) enables access control. Its support for AWS CloudTrail provides visibility into which packages are in use and where they can easily be updated or removed.
Using containers to modernize existing apps make them portable, increases development agility and reduces operational costs. The problem is that the process requires numerous manual tasks that are time-consuming and error-prone, and slow down modernization efforts.
That’s why we think another recently deployed AWS service will have a positive impact on the app development process. AWS App2Container is a command-line tool that helps containerize existing apps running on-premises, in Amazon EC2 or in other clouds with no code changes required.
App2Container discovers apps running on a server, identifies their dependencies and generates relevant artifacts for seamless deployment to Amazon ECS and Amazon EKS. It also provides integration with AWS CodeBuild and AWS CodeDeploy for a repeatable way to build and deploy containerized applications.
AWS App2Container generates artifacts such as Dockerfiles, container images in Amazon Elastic Container Registry (ECR), ECS Task definitions, Kubernetes deployment YAML, templates to set up a build/release pipeline in AWS CodePipeline and more.
It can also be used to containerize ASP.NET (.NET 3.5+) web apps running in IIS 7.5+ on Windows and Java apps running on Linux.
Another handy tool that debuted this summer is Amazon CodeGuru. Powered by machine learning, this set of tools automatically reviews code for bugs and suggests potential optimizations. It includes two components:
One more recently released AWS service we want to mention is Amazon Honeycode. This one has the potential to be a big time-saver for customers. The fully managed, low-code/no-code development tool makes it easy to build powerful mobile and web apps quickly with no programming required.
Customers can use a simple visual app builder to create highly interactive web and mobile apps, backed by an AWS-built database to perform tasks such as tracking data over time and notifying users of changes. They can get started creating apps in minutes and build applications for up to 20 users for free. After that, they pay per user and for the consumed storage capacity.
AWS is continually developing and deploying services that make app development easier and more cost-efficient. You can put these new services to work to innovate more, get to market quicker, generate significant cost savings and much more.
Microsoft scored a huge victory by sweeping in and taking the $10 billion dollar, multi-year JEDI contract for military IT services from AWS (owned and operated by amazon.com, its parent company). The backstory on this is that James “Mad Dog” Mattis, then Secretary of Defense, met with Jeff Bezos who tweeted about it on August 10, 2017 and it appears that Mattis decided to structure a request for IT services (now known as the JEDI contract) that all but led to AWS being crowned the winner by the way the bid was structured.
However, this was not to be. Not only was Mattis gone by January of 2019, but President Trump and Jeff Bezos were having public squabbling matches regarding coverage of the Trump administration in the Washington Post (which Jeff Bezos had purchased in 2013). So tenuous is their relationship that Trump mocked Bezos on Twitter regarding his divorce which was precipitated by the leaked private messages and pictures between Mr. Bezos and his mistress.
What does this all have to do with JEDI? Quite a bit, actually. Amazon has won a perhaps Pyrrhic victory by getting an injunction and getting any work to stop on the process of implementing the JEDI contract on Microsoft’s cloud. Amazon is posting a $42 million bond to cover any costs the government or Microsoft might incur if it turns out that this stoppage is unjustified—not small beans, but not a lot of money to either of these tech titans.
Which way does this jump ball go now? It seems like Microsoft would still have the upper hand, because they as well as the U.S. government would have contemplated this outcome when they decided to switch to a Microsoft solution at what seems like the last minute.
Amazon makes a compelling case as well: Because of the public animosity between two feuding billionaires, one a president, and one the richest man in America, government officials would be afraid to award a contract to Amazon’s AWS because they would suffer the wrath of Trump and his officials. The Trump administration has made it no secret that there is a revolving door for people who don’t get with the Trump administration and its policies. Sounds like a win for Amazon, right?
At the same time, Jeff Bezos’s leaked text and pictures between his mistress bring up a larger question: How can the U.S. government trust some of its most precious data when the CEO not only leaks such personal information, but it is so public that Mr. Bezos himself discussed what he considered ransom demands from a tabloid that threatened to cover it on a blog post on Twitter. Even worse, supposedly the pictures and texts were obtained by the leader of Saudi Arabia, a foreign country, through a bug in WhatsApp that allowed installation of malware on Jeff’s phone that allowed all the data from his phone to be siphoned off to a foreign entity. It’s difficult for AWS to say they are the best solution when their own CEO admits that his most personal data (a secret affair with his mistress) was stolen. What would happen to real military secrets if Amazon’s CEO can’t protect his own?
The fallout from all this is what you’d expect. More arm waving, conjecture and confusion. The reality is this opens up the field to other players such as Google and Oracle. At the same time, there are hundreds of other clouds that may be able to make a case that they are a best fit for certain applications since they may specialize in specific compliances, such as SOX, PCI or HIPAA.
Ultimately, this calls into question whether the government should be putting all its cloud eggs in one basket. The longer-term solution is that the government needs to dictate a series of APIs that its developers and contractors use, and that all compliant clouds would be required to support. This would alleviate the problem of centralizing resources on a single vendor’s solution.
In the medium term, lots of fireworks, lots of drama and most likely Microsoft, the original software empire, striking back and keeping the JEDI contract—one that was Amazon’s to lose. But the story isn’t written so we all need to keep watching for the return of the JEDI to see where this finally ends up.