John Carnell wrote:Hi Jesper,
I dont think Spring Boot is obsolete at all. I know several companies (including mine) that a build a majority of their services in Spring Boot or are adopting it. Also you have to remember in the end Spring Boot just builds down to a executable jar or war. You still need a server or container to run service. For our application we have Spring Boot based services deployed on both standalone AWS servers and in Docker containers. Since, we let the teams choose their own technologies so teams have chosen to deploy their Spring Boot based applications using Docker.
In my book, I build all of services and the Spring Cloud services using Spring Boot and then deploy the Spring Boot based services using Docker. In Chapter 10, I deploy all of the Spring Boot-based services that I built into Docker containers to Amazon ECS (Amazon's Docker Container Service). I do think microservices will become a dominant architecture. The only real question I see is whether or not the deployment model of a microservice will change. Will development teams continue with a server/container model or will more companies deploy their microservices as Functions-as-a-service (e.g. Lambda). The other wildcard in the mix from a deployment model is UniKernels. Last quarter, during our semi-annual Hackathon I actually worked on team that deployed a Spring-Boot service using a Unikernel. A Unikernel is single memory address space with almost no operating system. Unikernels startincredibly fast and because there is almost no operating system present for the kernel to run have a very small attack surface from a security perspective.
Randy Maddocks wrote:
...if you are trying to persuade someone to make an important decision, you want to make it immediately clear why the decision is relevant to their life (or business, or money, whatever the topic is). If people don’t see why something is relevant, they don’t pay attention to the details.
Very true - if I am trying to convince clients how including a certain feature in the web app is critical, explaining the intimate details of the code itself likely wouldn't peak their interest or maybe even win them over. However, telling them that it could save their users half a day's or more work efforts would go a long way in convincing them!
All the best Victor!
Victor Yocco wrote:Hi Palak,
Thank you for the question. I believe usability testing is a critical component of informing design thinking. We have an obligation to understand where our users might struggle with our product. We should proactively attempt to address these areas. Usability testing or empathy testing as you have described it is one of the best ways to collect data on these areas. I engage in usability testing as a regular part of my job. I advocate inserting usability testing from the beginning and throughout the product development cycle. You can test anything from wireframes as you mention, to a live product.
How far should one go? That is very subjective. I think you will find value in testing with at least 6 and up to 10 users around a specific set of tasks. You will identify most of the major usability issues. The goal is to try to continually refine the product to the point where only the extreme cases might cause people to struggle. Limitations of time, budget, and technology will always be an issue. My approach to usability testing is do it early and do it often. Make updates based on the feedback. Test again when you have more features or flows developed.
Oh, and try to get a diverse range of users in terms of their expertise and how they might use your product.
How have you used usability/empathy testing in your practice?
Monica Shiralkar wrote:HBase?
wrote Most of the NOSQL DBs like MongoDB provide a querying API. Without a querying API, there is no use of a DB.
How does it apply to the case of HBase?
Lanny Gilbert wrote:
My *actual* question, broadening the original question, is: Does anyone know of a good site or checklist that has something along the lines of "If you need to do <some list of things>, then you should probably use <traditional RDBMS, MongoDB, CouchDB, Cassandra, etc.>?
paul nisset wrote:Thanks Palak.
I do use Spring in a lot of projects, so this is very useful info.
Currently,we are using Spring /Hibernate but I should definitely read up on Spring Data.
It is probably more flexible.
Ian Miell wrote:
This is why our book contains a lot of material considered 'impure' Docker - ie not microservices, monolithic and not highly orchestrated 'data centre as an operating system' type work.
Docker helped us turn our monolithic application into a single unit which could be easily shipped for testing or support or dev purposes. We wrote our own simple automation tool to help achieve this - ShutIt