David Sachdev

Ranch Hand
+ Follow
since Oct 18, 2011
David likes ...
Java Mac
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
2
Received in last 30 days
0
Total given
3
Given in last 30 days
1
Forums and Threads
Scavenger Hunt
(keep public parts private until JForum day)
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by David Sachdev

Richard Rodger wrote:Hey David,

So I’m a little radical when it comes to service discovery these days - I like to use SWIM https://asafdav2.github.io/2017/swim-protocol/

The weak point in any component model ( that’s what microservices are!) is identity. Component A has to know about component B to send B messages. A also has to know what messages B can accept.

Example: network location, rest URLs, message bus topics, kubernetes host env vars, ... all the same thing.

To remove the concept of identity, you want to be able to just send messages without knowing where to send them.

This is fundamentally impossible of course, but you can weaken identity significantly by using something like SWIM. Essentially each microservices builds its own internal, but hidden, routing table.


Richard



Thanks Richard - in essence the problem comes back to what the Service Bus was trying to solve - consume the message and know where to send it to next.  And as you mention there is a security aspect there. I live in the world of ICAM, where SSO has to be factored in, and micro services has to factor that in as well. I'll take a look at SWIM, and the presentation that you linked to.  Seems interesting.

Thanks
David Sachdev
2 weeks ago
Sometimes I think that the biggest push for our organization to move to microservices was to help our 10 teams of 10 work independently - and that allowing the different parts of the system to work, deploy, (and fail) independently was secondary.  Do you have any advice on how to 1) start to move a large Spring application to Micro-services, and how to 2) move large teams of teams to a microservices mindset. While the move has been underway for a while, and we've got some services live - it has taken much longer then anticipated, and we can definitely say that there are some lessons learned, but I'm also thinking there are plenty more lessons for us to learn.  What are the wisdoms you can share  on large applications and large teams?

Thanks
David Sachdev
2 weeks ago

Mainak Biswas wrote:There is a catch here, as I was alluding to in the other thread. When webservices was the new kid in town, (the established ones being RPC, EDI etc etc.) UDDI was the mechanism for this. So as a concept it was there, and actually was way ahead of its time but the implementation was that hard; today on the other hand Zookeeper is way more implementation friendly,usable.  Certainly this is not something we come to know due to Microservices.



Thanks - let mew read/review the other thread - and see if I have any follow-ups.

Thanks
David Sachdev
2 weeks ago
Service Discovery is nothing new to us - JNDI, SOA, so many others - as well as tons of custom solutions.  How important do you think that Service Discovery is to o allMicroServices - versus having the services have their own map of microservices.  This starts to remind me of Inversion of Control concepts and using Spring Context Files for handling the mapping of java Objects.

So I know that there are various options for security discovery, such as Zookeeper and Consul.  We were considering Consul for other uses such as Event notifications, but I guess having a service come online is an Event.  I assume that you can use Service Discovery to also keep multiple versions of APIs up and running to allow everyone to migrate to the new versions.  On that note, what do you use for API versioning?

Thanks
David Sachdev
2 weeks ago

Nell Frédéric wrote:

For example if you take a classic SOA a good approach would be to migrate only the critical parts into MS. And even MS Architecture is an SOA Architecture (not a classical one, but it's one). You can have a classical SOA, a Domain Driver SOA or a MS SOA. But for me they are all SOA's... They just have different purpose and solve different problems. But MS Architecture could have been set up since REST was invented... It just it wasn't making any sense to have 100 Applications servers. It just became trendy because of the development of IaaS and PaaS solution.

But that's my point of view and I'm probably partially wrong.




That also brings up another question - does MicroServices and Containerization go hand-in-hand, or is it just that it is the preferred methodology to allow for many services, but without over-use of resources.  I know we can run multiple servers on a single machine, but containerization is much easier.

So curious, in this new world, do you run Docker on your local machine, dev version of OpenShift, something else?  Also what new tools are in your toolbox in the micro-services world?

Thanks
David Sachdev
2 weeks ago
Looking at Chapter 2, I love that you mention that we are working in real life - in a messy world of grown-ups.  I the "conventional" definitions that you provide on:

1) self-contained (100 lines of code max)
2) independent deployable processing communicating asychronously
3) Microservices are mini web servers offering a small REST-based HTTP API that accepts and returns JSON documents.
4) A micro-service is an independent software component that takes no more than one iteration to build and deploy

if I rank them in importance it would probably be in my mind 2, 3, 4, 1 - and in fact the 100 lines of code is kind of off-putting to me, but maybe I need to change my thoughts on that. Given the need for "independence" that may require its own data-store, if we keep microservices so small, might we end up needing too many resources on the data storage side?  Also, what can we learn from the world of Service Oriented Architecture (SOA) that we can use as lessons learned when writing microservices?

Thanks
David Sachdev

2 weeks ago
Welcome to the forum!  Looking forward to the interesting discussions!
2 weeks ago
So we have our builds fully automated using Chef and utilizing Chef vault for environmental variables and encryption of things such as passwords.  We want to be able to leverage our previous work as we move towards containers.  I did go to a Chef conference recently where they suggested looking at Habitat, but it would seem that this is a common issue as shops migrate.  We are thinking we can create a Chef recipe to create the container file and still use the same vaults for storage for now.  Do you have a recommended path for this migration?  Thoughts on encrypting passwords and other secrets in a CI/CD world targeting containers, tips and tricks?

Thanks
David Sachdev
3 weeks ago
So we have about 10 large applications to over from a Chef/EC2/Java and/or Rails deployment to a containerized platform.  Then standard at my organization is OpenShfit (just went live recently - but we have dev/test and preprod/prod clusters up).  But there is some holdout by a few individuals who think that our own Mesos build on AWS would be better and cheaper.  My research says that if you have a massive application that needs to scale to extremes, then Mesos might be the right choice, but Kubernetes has gained steam and traction - and AWS:ReInvent helped to solidify it as the choice in the VHS versus BetaMax showdown of 2017.  Thoughts?

3 weeks ago
I know that there are a lot of Kubernetes implementations to choose from.  We are using OpenShift and have a few prod and a few non-Prod clusters up - but with the new EKS from Amazon announced, I can see the likelihood of my organization moving there. What to you are the "defacto" implementations for the coming year that we should be looking at?  OpenShift seemed like it was the place to be - until AWS made their announcement in Vegas last month.  I just want to make sure we are making the right choice for the future.  While containerization does offer us portability, there is still quite a bit of work that has been put into the OpenShift effort, and we don't want to change plans every time the wind blows (although it happens here sometimes)

While the organization is on OpenShift, we could opt for the EKS route - as long as we managed it ourselves.  In general, managing our own infrastructure in AWS has been better then having a secondary team in the mix.  (Just a bit of additional details on why we may still have a choice)
3 weeks ago
Welcome Marko Luksa - I love almost every "In Action" book, and I'm diving in head first to Kubernetes!  I have about 10 apps that have to be converted in the coming months, and a demo that we are delivering on a Kubernetes platform on Monday. Questions galore coming your way!
3 weeks ago

Ashish Sarin wrote:Hi David,

The first chapter does mention about what has changed in Spring 5. It points to chapters where you can find details about those changes in the book.

regards
Ashish



Great - I'll have to check that out!  Thank you!
1 month ago

Ashish Sarin wrote:Hi David,

This book is 'ideal' for someone who has never worked on Spring Framework.

regards
Ashish



Thanks - how about for those of use that have worked with Spring for a while.  Does it make it easy to get up to speed on new features, and maybe let us know to stop  doing things in order styles/ways?

Thaanks
David

1 month ago
I've been using Spring for a number of years, but have been a bit more DevOps/CI/CD and Cloud based over the last few years.  I'm going to be leading a team into some new Java endeavours and I'm looking forward to checking on the book - and hope that for someone that is well versed in Spring 3, and has experience with Spring 4 - what is new, what is improved and what should essentially should be "deprecated" from use.  Does the book have a section that covers this, or is it just spread out throughout the book?
1 month ago
I am curious to know if this book is good for people new to Spring as well?  Does it go into the concepts of Inversion of Control (IoC) and Dependency Injection (DI) or does it expect that users are going to already be familiar with this concept.  We've got a range of users on this team, and there are some that are new to Spring, and I'm wondering how much the basics are covered.  Also - given that IoC and DI really help push the use of Unit Testing - is Unit Testing something that is covered throughout the book as a general part of coding, etc.

Thanks
David Sachdev

1 month ago