I liked my previous post's title so much that I have decided to spin up a new blog dedicated to my experiences and observations in the development and operation of microservices.
The title is, "New adventures in microservives," and you can find it at the following URL:
https://ms-blog.elegant-solutions.london/
You'll have to excuse me if I don't go into specifics about where or when I have encountered the issues that I will post about. There are not horror stories or embarassments that I can recall, it's just professional courtesy not to disclose irrelevant details.
Stephen Souness, a Java developer recently returned to New Zealand sharing some thoughts on what's happening in the world of Cloud computing, Java and database technologies.
Monday 28 October 2019
Friday 25 October 2019
New adventures in microservices - reducing inter-service calls
Not so long ago I was working on a product that internally exposed an API to allow clients to keep in sync with a user's most recently read documents. I expect most readers of this blog will have used Amazon's Kindle or a similar online reading application so I won't have to explain any of the fundamentals of this functionality.
On the surface this "recently read" service was quite simple - just read the user's most recent records out of a specifically designed database table and present it to the client application.
A complicating factor in this particular system was that some documents belong to a group rather than an individual user, and as a result the rights to access documents could change over time.
I consider this to be a case study of when catering for an edge case can lead to unnecessary pressure on core systems. Approximately 75% of calls to the documents service were permission checks from the recently read service.
All of the clients of the recently read service would silently ignore any reference to a document that the client did not have, so the permission checks were completely unnecessary.
After consulting with the various teams involved I removed the permission checking calls and as a result the response time of the recently read service improved, and the load on the documents service reduced significantly. As a result the documents service was able to run with fewer instances.
This was one of the rare cases when the best way to improve the performance of a service call was to remove it altogether.
On the surface this "recently read" service was quite simple - just read the user's most recent records out of a specifically designed database table and present it to the client application.
A complicating factor in this particular system was that some documents belong to a group rather than an individual user, and as a result the rights to access documents could change over time.
I consider this to be a case study of when catering for an edge case can lead to unnecessary pressure on core systems. Approximately 75% of calls to the documents service were permission checks from the recently read service.
All of the clients of the recently read service would silently ignore any reference to a document that the client did not have, so the permission checks were completely unnecessary.
After consulting with the various teams involved I removed the permission checking calls and as a result the response time of the recently read service improved, and the load on the documents service reduced significantly. As a result the documents service was able to run with fewer instances.
This was one of the rare cases when the best way to improve the performance of a service call was to remove it altogether.
Labels:
microservice,
microservice efficiency,
performance
Wednesday 23 October 2019
Recent Holiday Reading
Travelling to the other side of the world offers plenty of idle time in the airport shops. Turning up to the airport three hours before the flight is a given, when considering the hassle and cost involved if the first flight is missed.
Even if I have a book or two in my carry on bag I still peruse the paperbacks shelves at WH Smith or the local equivalent airport retailer.
So, here's a list of books that I have been reading during my latest holiday...
Technology books (on Kindle - since typical bookshops don't have these titles)
Site Reliability Engineering - How Google Runs Production Systems
Kubernetes Patterns - Reusable Elements For Designing Cloud Native Applications
Accelerate - Building and Scaling High Performing Technology Organizations
Not so technology books
Eric Idle - Always Look On The Bright Side Of Life
Permanent Record (Edward Snowden)
Even if I have a book or two in my carry on bag I still peruse the paperbacks shelves at WH Smith or the local equivalent airport retailer.
So, here's a list of books that I have been reading during my latest holiday...
Technology books (on Kindle - since typical bookshops don't have these titles)
Site Reliability Engineering - How Google Runs Production Systems
Kubernetes Patterns - Reusable Elements For Designing Cloud Native Applications
Accelerate - Building and Scaling High Performing Technology Organizations
Not so technology books
Eric Idle - Always Look On The Bright Side Of Life
Permanent Record (Edward Snowden)
Labels:
Accelerate,
kubernetes,
Site Reliability Engineering
Interview preparation
I had a mental blank while attempting to jot down some code for solving a problem on paper during a recent job interview. Less than a minute after leaving the interview I remembered the name of a method that I should have been using instead of my clunky array manipulation. I put the experience down to a combination of being so reliant on IDE code completion, and not having written much code for a couple of months while I have been unwinding on holiday.
Alas, even my depth of knowledge on changes to HashMap’s implementation (List gets replaced by tree when 8 elements fall under the same bucket since Java 8) did not balance out for that particular glitch.
Oh well, it was always going to be unlikely to ace the first interview after a four year break.
Alas, even my depth of knowledge on changes to HashMap’s implementation (List gets replaced by tree when 8 elements fall under the same bucket since Java 8) did not balance out for that particular glitch.
Oh well, it was always going to be unlikely to ace the first interview after a four year break.
Preparing for interviews versus skating to where the puck is going to be
"I skate to where the puck is going to be, not to where it has been." - Wayne Gretsky
I'm in the process of seeking out a new challenge in my career (no need to whisper - I've left my previous job on good terms and taken a nice long holiday - so I'm not sneaking around to speak to recruiters during work time).
While updating my CV I have been quite aware that once again I find myself without professional experience of the latest popular technology in my sector - Kubernetes ... and maybe Kafka.
It's very tempting to go away and complete a full-on course to fill in the gaps, but I've been in the industry for long enough to appreciate that there's still a reasonable chance that my next role might not include those technologies anyway.
So, for now I'll just have to find the right balance of revising what I already know, and reading about and watching videos about enough to be able to carry my end of a conversation.
I'm in the process of seeking out a new challenge in my career (no need to whisper - I've left my previous job on good terms and taken a nice long holiday - so I'm not sneaking around to speak to recruiters during work time).
While updating my CV I have been quite aware that once again I find myself without professional experience of the latest popular technology in my sector - Kubernetes ... and maybe Kafka.
It's very tempting to go away and complete a full-on course to fill in the gaps, but I've been in the industry for long enough to appreciate that there's still a reasonable chance that my next role might not include those technologies anyway.
So, for now I'll just have to find the right balance of revising what I already know, and reading about and watching videos about enough to be able to carry my end of a conversation.
Labels:
career break,
interview preparation,
kubernetes
Tuesday 22 October 2019
How NOT to use LinkedIn
I've recently taken the decision to look for a new job. Much like most of my other career moves I have chosen to leave a comfortable position, treating looking for the next one as a full time endeavour - rather than being sneaky and booking a "dentist appointment" or taking time off to attend interviews.
In this modern era I thought that I would not need to update my CV, as LinkedIn is the go to place for publicising that I am available, and I have kept my profile there relatively up to date and complete.
My main discovery of the last few days has been that the "Projects" section in a LinkedIn profile is not very prominent. For example, if I choose to export my profile as a PDF document then none of the project information will be included.
The significance of this issue was reinforced when I attempted to export my LinkedIn profile across to a third party system as part of applying for a job. Sure enough none of the project information was carried across.
With this in mind, I will be restructuring my profile so that the key aspects of my project experiences will also be mentioned in the high level description section for each job that I have held. This should prevent the unpleasant experience of having to fill in a lot of gaps in face to face interviews where interviewers have only seen the top level of my LinkedIn profile as that has been provided to them by their recruiter.
I've also seen this situation as a reason to finally get around to buying and installing Word on my Mac, rather than cranking up my 11 year old Windows laptop for updating a CV to circulate.
In this modern era I thought that I would not need to update my CV, as LinkedIn is the go to place for publicising that I am available, and I have kept my profile there relatively up to date and complete.
My main discovery of the last few days has been that the "Projects" section in a LinkedIn profile is not very prominent. For example, if I choose to export my profile as a PDF document then none of the project information will be included.
The significance of this issue was reinforced when I attempted to export my LinkedIn profile across to a third party system as part of applying for a job. Sure enough none of the project information was carried across.
With this in mind, I will be restructuring my profile so that the key aspects of my project experiences will also be mentioned in the high level description section for each job that I have held. This should prevent the unpleasant experience of having to fill in a lot of gaps in face to face interviews where interviewers have only seen the top level of my LinkedIn profile as that has been provided to them by their recruiter.
I've also seen this situation as a reason to finally get around to buying and installing Word on my Mac, rather than cranking up my 11 year old Windows laptop for updating a CV to circulate.
Monday 21 October 2019
Contributions to open source - it's not just about hardcore coding
Just a listing of some contributions that I have made to open source software, from creating my own code to making a third party's documentation a little bit more readable.
Created plugin for GoCD continuous integration server to enable polling of status of application in Cloud Foundry.
https://github.com/Sounie/springer-gocd-cloudfoundry-plugin
- Identified code change in Apache Camel that resulted in messages being deleted from an AWS SQS queue even when the application logic encountered an error path.
At the time we had a situation where a regular trickle of events would normally fail to process, resulting in retries and ultimately being automatically moved onto a dead letter queue.
When the DLQ stopped receiving messages it took a while to trace back what had changed. As an aside, this type of situation can be considered as a good motivation for making small distinct changes - this is where a continuous deployment pipeline is a real enabler.
CAMEL-9405 - Amazon SQS message deletion behaviour change on exception
- vavr (formerly known as javaslang).
Some wording tweaks
- Jenkins CI
Bugfix in translation perl script
- AdoptOpenJDK Docker image scripts
Correction to comment
- IntelliJ IDEA Findbugs plugin
Typo in label shown in IDE
Created plugin for GoCD continuous integration server to enable polling of status of application in Cloud Foundry.
https://github.com/Sounie/springer-gocd-cloudfoundry-plugin
- Identified code change in Apache Camel that resulted in messages being deleted from an AWS SQS queue even when the application logic encountered an error path.
At the time we had a situation where a regular trickle of events would normally fail to process, resulting in retries and ultimately being automatically moved onto a dead letter queue.
When the DLQ stopped receiving messages it took a while to trace back what had changed. As an aside, this type of situation can be considered as a good motivation for making small distinct changes - this is where a continuous deployment pipeline is a real enabler.
CAMEL-9405 - Amazon SQS message deletion behaviour change on exception
- vavr (formerly known as javaslang).
Some wording tweaks
- Jenkins CI
Bugfix in translation perl script
- AdoptOpenJDK Docker image scripts
Correction to comment
- IntelliJ IDEA Findbugs plugin
Typo in label shown in IDE
Sunday 20 October 2019
Google Search Console
A couple of years ago I realised that website owners can obtain access to information about how users on Google end up reaching their site via Google. Now I'm getting around to setting that up for this blog site.
I'm not expecting any high numbers of visitors, but am a little bit curious to see which page of search results my content show up on - and what sort of terms users are entering to reach here.
I'm not expecting any high numbers of visitors, but am a little bit curious to see which page of search results my content show up on - and what sort of terms users are entering to reach here.
Labels:
Google search console,
Google webmaster tools,
SEO
Friday 11 October 2019
Takeaways from JAX London 2019
I attended the JAX London "The Conference for Java and Software Innovation" earlier this week. It was a great opportunity to keep up to date with what is happening with the core technologies that I have been using in my day to day work for most of my career so far. This post is a brief summary of some of my favourite tidbits.
In serverless computing size matters - smaller containers and apps mean less time is required for data transfer, and fewer class files mean less time for class loading which all feeds into how long it takes for the environment to be ready to execute.
Later releases of Java no longer have the concept of separate smaller JRE. If you want to deploy applications without the full JDK then jlink can be used to build a custom runtime image which only includes the modules that your app requires.
Efficiency improvements at scale can have environmental benefits - requiring fewer servers to perform the same work means less electricity is consumed.
It's okay to not know about every technology out there. Just as I was contemplating building up a mindmap of major technologies and the main current implementations, the presenter up front described how many different aspects there now are to software development - development tools, languages, deployment containers, continuous integration systems, service meshes, content delivery networks... - that's just some of the back end, I can't imagine anyone keeping a straight face when claiming to be a full stack developer and keeping up to date to the same extent.
Sometimes incrememental improvements will be the best path to improving an existing system. Measure what it is currently doing, adjust something that looks like it is having an impact on the key performance indicator then measure again - rinse and repeat.
Other times it's best to throw away and start again - e.g. garbage collection settings when upgrading JDK version. The settings that made sense on Java 8 may not be necessary or optimal in Java 11. This will really be the case if you're using CMS as that is not expected to even exist in later versions of the JDK.
JVM startup time regressed from Java 8 to Java 9, but has improved in subsequent releases. That might explain why AWS's Lambda implementation didn't move forward from Java 8 to Java 9 (not being a long term support version would also be a factor).
In serverless computing size matters - smaller containers and apps mean less time is required for data transfer, and fewer class files mean less time for class loading which all feeds into how long it takes for the environment to be ready to execute.
Later releases of Java no longer have the concept of separate smaller JRE. If you want to deploy applications without the full JDK then jlink can be used to build a custom runtime image which only includes the modules that your app requires.
Efficiency improvements at scale can have environmental benefits - requiring fewer servers to perform the same work means less electricity is consumed.
It's okay to not know about every technology out there. Just as I was contemplating building up a mindmap of major technologies and the main current implementations, the presenter up front described how many different aspects there now are to software development - development tools, languages, deployment containers, continuous integration systems, service meshes, content delivery networks... - that's just some of the back end, I can't imagine anyone keeping a straight face when claiming to be a full stack developer and keeping up to date to the same extent.
Sometimes incrememental improvements will be the best path to improving an existing system. Measure what it is currently doing, adjust something that looks like it is having an impact on the key performance indicator then measure again - rinse and repeat.
Other times it's best to throw away and start again - e.g. garbage collection settings when upgrading JDK version. The settings that made sense on Java 8 may not be necessary or optimal in Java 11. This will really be the case if you're using CMS as that is not expected to even exist in later versions of the JDK.
JVM startup time regressed from Java 8 to Java 9, but has improved in subsequent releases. That might explain why AWS's Lambda implementation didn't move forward from Java 8 to Java 9 (not being a long term support version would also be a factor).
Subscribe to:
Posts (Atom)