Colm MacCarthaigh – Sr Principal Engineer, EC2 Networking, AWS
One of the undeniable aspects of AWS is its scale. We can think of this scale from two perspectives. From a customer perspective, AWS offers so many services in so many regions that you can build some amazing global applications at scale on top of the AWS cloud. The other perspective is from the AWS side as a huge cloud operator at scale. The AWS cloud shouldn’t be seen just as a (long) list of separate services tied together but should rather be looked at from the bottom up as a massive distributed system. I sometimes explain the AWS cloud as a distributed operating system to help people understand how tightly bound the services are on a common scalable platform. The AWS “OS” has many thing like networking, storage, compute and security services, just like Windows, Linux or Mac does but massively more distributed. AWS CTO, Werner Vogels, is one of the world’s distributed systems experts. The AWS cloud is a system designed for scale.
Read more…
Andy Reedy, Aarthi Raju and Wen Yu from AWS
Being a long time VMware customer, I’m very interested in what VMware Cloud on AWS (VMConAWS) could offer. Its early days and I’m not sure what customer take-up has been so far but there is certainly industry buzz, attention and interested customers. Its VMware’s current big push to be seen as a cloud company. One of the criticisms levelled at VMConAWS is that its just a glorified colo, moving your current virtualisation layer from an on-prem or existing colo to another colo, this time hosted by AWS. AWS, however, isn’t just another colo!
One of the obvious big benefits with hosting your VMware workloads is being close to the rest of what AWS offers. This could be the hook to help you decide to use the service as VMConAWS comes with built-in integration with native AWS services. Are these integrations just a way to get you to use more AWS when you’re a VMware customer and in time shrink your VMware investments as you take advantage of more AWS native services? Time will tell but the integrations with native AWS services could be very useful if you’re wanting to migrate and host your VMware workloads in a new “colo”.
Overview
Read more…
Mike Mackay, Toby Knight, Bastien Leblanc, Imran Dawood, Mike Morain, Andrew Kane, Samuel Waymouth, Lee Packham, all from Amazon and Charles Wilkinson Architecture Head from River Island
This was a retail focused workshop which although not in my normal sphere of interest piqued my interest as its a great example of designing technology for massive, seasonal scale. There’s a difference between designing a system for continuous scale and one for rapid change scale. Black Friday has just happened so the reasons are fresh in our minds. Cost is obviously a factor, you don’t want to be paying for your peak system needs when they’re not being used.
Part of the consideration is being able to satisfy all transactions going through the system when its sale time. Parts of the system are being flooded with sale related requests, yet the non impacted parts of the system must not be squeezed. You can’t let the rest of your IT fall over because just ‘re doing a sale
The workshop used AWS Lambda, Amazon SNS, Amazon SQS, and Amazon API Gateway with existing non-microservices backend systems to divert traffic from the core critical infrastructure using Amazon CloudFront and AWS Lambda@Edge.
You can also play along at home with the instructions https://docs.lee.fishing
Set up
Read more…
I arrived in Las Vegas from London via LAX yesterday, so a long time sitting in a plane. Thanksgiving weekend is actually a good weekend to travel as its quieter than normal. I caught up with none other than This Week in AWS host, Corey Quinn. I then stretched the legs and saw a show to stay up and adjust the body clock.
I slept reasonably well for being 8 hours out of sync, did a run to resync and clear the head then more than cancelled out any good will with a breakfast buffet, Vegas style! Lovely!
Registration
Registration was pretty simple, it was different from last year as its only at The Venetian and Aria hotels so you couldn’t register at a smaller venue. You can however register at the airport on arrivals at baggage reclaim which is a nice addition, if you’re arriving from today. Lot of people expected obviously and it looks like so far the Amazon People Queuing System (PQS) is working at scale. Registration allowed you to get a hoodie which is actually pretty comfortable and doesn’t scream “IT clothing” too much!
Managed to also bump into Eric Wright, Gregg Robertson and Chris Porter so re:Invent is also starting with a good community social vibe!
Read more…
Many enterprises require replacing all vCenter certificates with Enterprise CA trusted certificates.
vSphere 6.5 has made the certificate updating process so much easier than the complication of the vSphere 5.x days.
Basic vCenter now has a single Machine SSL certificate as well as four Solution user certificates: machine (different from machine SSL), vpxd, vpxd-extension, vsphere-webclient.
Although the Solution user certificates are only used for internal vCenter communication, many enterprise security standards require using enterprise CA issues certificates for everything.
BTW, when you migrate from a Windows vCenter 5.5 to VCSA 6.5 using the excellent migration tool, only the Machine SSL certificate is taken across, the Solution user certificates remain self-signed and may need to be manually updated.
Each Solution user certificate needs to have a unique name.
Also remember, the SubjectAltName must contain DNS Name=machine_FQDN
I used the great guide from Ian Sanderson for updating the certs as a base https://www.snurf.co.uk/vmware/replace-ssl-certificates-on-vmware-psc-v6-5/
You can use the VMware supplied vSphere Certificate Manager in the VCSA (sidebar, you should really be using the VCSA rather than Windows by now!) to generate the solutions user certificate.
/usr/lib/vmware-vmca/bin/certificate-manager
When you select Option 5 and then Option 1 to generate the certificate private keys and certificate signing requests to send off to your Enterprise CA, the tool has a particular format for the signing requests.
Read more…
I was recently invited to do an internal enterprise financial company presentation on serverless computing as part of a general what’s happening in IT series. There was a wider range of people than I expected who attended, some business people and some IT people.
The business lens
In the questions and feedback afterwards interestingly some of the business people could see some of the value more easily than the IT people. Business people liked the coming together of business logic and IT and could see the benefit of just encoding what they need doing in a serverless function without having to worry as much about all the IT infrastructure stuff behind the scenes. Although the business people weren’t coders, someone likened the approach to using Excel macros. Some fairly sophisticated Excel functions have graced the trading desks of many an organisation. They didn’t need to think about infrastructure with Excel Macros, Excel was just a platform you could code mathematical functions in. Sure, Excel macros had many issues, security, performance, availability etc. but they served the business need easily without having to get IT involved.
The IT lens
I then spoke to a development team leader afterwards. She’s very well versed in coding, a super smart algorithmic trading developer. She voiced valid concerns though that with serverless functions you couldn’t control the latency of the function and so she couldn’t see any use for them in their work. Part of the workflow they develop is low-latency trading, pricing and analytics which of course is very latency and performance sensitive. Some of the workflows include many steps necessary for compliance and auditing. A price range traded may need to be put into a database to reference later. A trade that is priced needs to be logged somewhere and a trade completed needs to go into another database which kicks off a whole other bunch of workflows to be reconciled in the back-office. She mentioned the low-latency algo stuff was working well but they sometimes struggled with performance and speed when it was a very busy trading day. Some of the compliance and auditing code sits very close compute wise to the low-latency code. This makes it simpler to code the end-to-end transactions but it means the most expensive physical server hardware low-latency compute cycles are also being “wasted” on compliance and auditing code which may struggle to keep up on an extra busy trading day. To improve this would generally require scaling up existing compute resources. The compliance and auditing data was also used by many other integrated systems so care needed to be taken so that the secondary databases could keep up with low-latency demand.
This made me think of two things, first of all how this application would of course benefit from some splitting up. The app could be changed for the low-latency code to push out the minimal amount of compliance and auditing information to another database, queue or even stream. A separate set of serverless functions could then very efficiently respond to an event or pick up these trades or prices and do whatever needs to be done (BTW, its not just functions that can be serverless, databases, queues and storage can be too!). This could also be massively scalable in parallel. 1 trade at a time or a million and this wasn’t latency sensitive stuff once the initial small record was created.
CAN use or CAN’t USE
Secondly was how the developer team leader was seeing how serverless functions COULD NOT be used for latency sensitive workloads but not seeing how useful they COULD be for all the rest of the compliance and auditing code. The low latency code was the most important so naturally her focus is on that.
The splitting up of the app is an architectural discussion and may not in fact be suitable in the end but the more important point is sometimes we are a little myopic and only see what a technology CAN’T do rather than looking at the bigger picture and seeing what it CAN do. This can distance you from the business. Oh, and of course, Excel can do a LOT!
I attended the AWS re:Invent conference a few weeks ago and based on my in-show blogging, ActualTechMedia asked me if I would do a review for them.
ICYMI – AWS re:Invent Recap
I also blogged up a storm while I was there…
Show Preview and Daily Buzz updates:
Blogged Sessions and Workshops I attended:
Breakfast
I headed to the Venetian to watch the keynote remotely. Have to mention the breakfast at the Grand Luxe Cafe which was Churros French Toast!
I certainly wasn’t expecting this, it was excellent!
Werner Vogels Keynote
AWS CTO Werner Vogels wanted to use the keynote not for a slew of announcements but rather to revisit the original AWS keynote with “21st century architecture re:Imagined” and set out what the architecture should be for the next few years.
I’m not going to go through the whole keynote as this is covered elsewhere but some things that I found interesting.
Human Interfaces
He talked about the importance of data and the interfaces to it. They will become more human rather than machine like voice with Alexa. Voice unlocks digital systems for everyone.
Alexa for Business was announced which will allow you to join conference calls easily and know where you are and who you are to automatically join a call. I wonder how this will all work in open plan offices. Werner says we need to start thinking about voice as an interface with a conversation rather than just a webpage output to interact with back end systems.
He then talked about the three different “planes”, Admin, Control and Data. I like the addition of the Admin plan which I haven’t seen before.
- He listed some architecture guidelines
- Stop guessing capacity needs
- Test systems in production
- Automate to make architectural experimentation
- Drive your architecture using data
- Improve through Game Days
Read more…
Tim Wagner the AWS Serverless GM and Jeet Kaul from FICO
This session was about new things in serverless.
Tim reiterated how mazing Lambda is coming, its even inside a camera which was announced in the keynote as well as the top memory size being doubled to 3Gb which also doubled the CPU power.
Magic!
There was a mini magic show which was apparently a nod to something they did last year.
The idea is to show disappearing servers, as there are more and more serverless offerings, this means more and more disappearing servers.
Serverless Application Repository.
It’s worth looking at the recently announces Serverless Application Repository, its a marketplace of serverless functions published by AWS and others.
Read more…
Ajay Nair from AWS and Peter Sbarski from A Cloud Guru
Another session on architectural best practices and a bunch of handy little things to help you out. It was advanced so no overviews required about “what is serverless”.
Multiple Points to Optimise
For normal optimisation with traditional application stacks you actually pack things together but for serverless you do the opposite, as its generally better and more scalable if things are spread out.
There are three components to look at, the interface via API Gateway or Alexa, the compute with Lambda and the data with S3, DynamoDB etc.
The main goal is to try and reduce latency which doesn’t just take time but also costs you more. The more functions you are stringing together the more latency issues will bug you.
The Lean Function
Anatomy of a function = the function + language runtime + functional container + compute substrate
When function invokes it:
- downloads your code
- starts new container
- bootstraps the runtime
- starts the code.
Everything before start code is cold start. AWS optimises stages 1 and 2 (and have had 80% improvement in latency for some scenarios) and your job is to optimise 3 and 4.
Try to make your logic as concise as possible:
- efficient / single purpose code
- avoid fat / monolithic functions
- control the dependencies in the package
- optimise for your language
You can also see the start times in X-Ray.
For Java avoid using the whole SDK aws-java-sdk directly, rather use the subcomponent aws-java-sdk-s3 or aws-java-sdk-dynamodb.
This reduces your dependency size
Ephemeral Environment
Read more…
One of the undeniable aspects of AWS is its scale. We can think of this scale from two perspectives. From a customer perspective, AWS offers so many services in so many regions that you can build some amazing global applications at scale on top of the AWS cloud. The other perspective is from the AWS side as a huge cloud operator at scale. The AWS cloud shouldn’t be seen just as a (long) list of separate services tied together but should rather be looked at from the bottom up as a massive distributed system. I sometimes explain the AWS cloud as a distributed operating system to help people understand how tightly bound the services are on a common scalable platform. The AWS “OS” has many thing like networking, storage, compute and security services, just like Windows, Linux or Mac does but massively more distributed. AWS CTO, Werner Vogels, is one of the world’s distributed systems experts. The AWS cloud is a system designed for scale.
Recent Comments